Skip to content

Test runners interfere with Java language server #260

Closed
Closed
Test runners interfere with Java language server#260
Assignees
jdneo

Description

@akaroml
Rome Li (akaroml)
opened on Jul 27, 2018

redhat-developer/vscode-java#592 One user is reporting that LS stops running occasionally. The issue was mitigated by disabling Java Test Runner.

Java Test Runner should not interfere with Language Server and stops it from working properly.

Activity

  1. Xuan Zhou (ansyral)
    changed the title [-]Test runners interfere with Java language server[/-] [+]Avoid updating codelens when the user isn't editing test files[/+] on Jul 27, 2018
  2. Xuan Zhou (ansyral)
    changed the title [-]Avoid updating codelens when the user isn't editing test files[/-] [+]Test runners interfere with Java language server[/+] on Jul 27, 2018

  3. ansyral commented on Jul 27, 2018

    @ansyral
    Xuan Zhou (ansyral)
    on Jul 27, 2018
    Collaborator

    the extension would observe the DidSaveTextDocument event and update the test storage(only the edited document) if user saves the document. Since the granularity is only one file, I don't think it would take that long time. So the action plan is:

    1. investigate whether there is a performance issue to fetch tests per document.
    2. investigate whether there is a way to check current text document is within a test project.

  4. aholstenson commented on Aug 5, 2018

    @aholstenson
    Andreas Holstenson (aholstenson)
    on Aug 5, 2018

    This occurs a lot for me and a colleague, several times a day if we're lucky and several times an hour if we're unlucky.

    Here is a capture of the stack trace of a thread when the Java Language Server stops responding:

    "Worker-2: Validate documents" #24 prio=5 os_prio=0 tid=0x00007fc93ca2a800 nid=0x67f3 waiting on condition [0x00007fc95d8c7000]
   java.lang.Thread.State: WAITING (parking)
	at jdk.internal.misc.Unsafe.park(java.base@9-Ubuntu/Native Method)
	- parking to wait for  <0x0000000723cedec0> (a java.util.concurrent.CompletableFuture$Signaller)
	at java.util.concurrent.locks.LockSupport.park(java.base@9-Ubuntu/LockSupport.java:194)
	at java.util.concurrent.CompletableFuture$Signaller.block(java.base@9-Ubuntu/CompletableFuture.java:1796)
	at java.util.concurrent.ForkJoinPool.managedBlock(java.base@9-Ubuntu/ForkJoinPool.java:3158)
	at java.util.concurrent.CompletableFuture.waitingGet(java.base@9-Ubuntu/CompletableFuture.java:1823)
	at java.util.concurrent.CompletableFuture.join(java.base@9-Ubuntu/CompletableFuture.java:2043)
	at org.eclipse.jdt.ls.core.internal.JavaClientConnection.executeClientCommand(JavaClientConnection.java:81)
	at com.microsoft.java.test.plugin.internal.JavaModelEventProvider.elementChanged(JavaModelEventProvider.java:55)
	at org.eclipse.jdt.internal.core.DeltaProcessor$3.run(DeltaProcessor.java:1735)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.jdt.internal.core.DeltaProcessor.notifyListeners(DeltaProcessor.java:1723)
	at org.eclipse.jdt.internal.core.DeltaProcessor.fireReconcileDelta(DeltaProcessor.java:1574)
	at org.eclipse.jdt.internal.core.DeltaProcessor.fire(DeltaProcessor.java:1533)
	at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:774)
	at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:799)
	at org.eclipse.jdt.internal.core.CompilationUnit.reconcile(CompilationUnit.java:1319)
	at org.eclipse.jdt.internal.core.CompilationUnit.reconcile(CompilationUnit.java:1278)
	at org.eclipse.jdt.ls.core.internal.handlers.DocumentLifeCycleHandler.performValidation(DocumentLifeCycleHandler.java:135)
	at org.eclipse.jdt.ls.core.internal.handlers.DocumentLifeCycleHandler.access$0(DocumentLifeCycleHandler.java:121)
	at org.eclipse.jdt.ls.core.internal.handlers.DocumentLifeCycleHandler$1.runInWorkspace(DocumentLifeCycleHandler.java:89)
	at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:39)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:60)

   Locked ownable synchronizers:
	- None

    The error occurs both with the Oracle distribution for Java 8 and the OpenJDK one for Java 9.

  5. julianosam commented on Aug 9, 2018

    @julianosam
    Juliano (julianosam)
    on Aug 9, 2018

    Confirming this happens every after a few minutes of use. Disabling the extension seems to make the issue go away.

  6. ansyral commented on Aug 9, 2018

    @ansyral
    Xuan Zhou (ansyral)
    on Aug 9, 2018
    Collaborator

    Thanks for the info, Andreas Holstenson (@aholstenson) Juliano (@julianosam) . We'll look into it this release. When did you start to meet this issue? I just want to make sure it is not a regression or something.

  7. julianosam commented on Aug 18, 2018

    @julianosam
    Juliano (julianosam)
    on Aug 18, 2018

    Xuan Zhou (@ansyral) It's hard to say for sure. But I can tell I started getting these errors about 6-8 weeks ago. Likely after the 0.7.0 release on 06/26?

  8. julianosam commented on Aug 25, 2018

    @julianosam
    Juliano (julianosam)
    on Aug 25, 2018

    Another thing I noticed is that, since I am using lombok in almost all of my Java projects, it seems to be easier to reproduce the issue when adding Lombok annotations to my classes. Maybe it's a coincidence, but I thought it would be worth mentioning.

  9. ansyral commented on Aug 27, 2018

    @ansyral
    Xuan Zhou (ansyral)
    on Aug 27, 2018
    Collaborator

    One finding is that Test Explorer would be refreshed as soon as test storage is updated. So if you are editing a test file and you have a project with many tests, then it would take a long time. To solve this, I plan to add incremental refresh feature for test explorer. Juliano (@julianosam) Andreas Holstenson (@aholstenson) is this the scenario where you're stuck while editing java files?

  10. julianosam commented on Aug 27, 2018

    @julianosam
    Juliano (julianosam)
    on Aug 27, 2018

    I never seen this happening while editing a test file, only source code (inside main folder). It happens much more frequently if I add/modify lombok annotations in the classes. What could this be impacting?

    Also, I work both on a Macbook and a Linux laptop. It happens much more frequently in the Mac. Only saw it a few times on my Linux pc. Could this be related to filesystem i/o maybe?

  11. ansyral commented on Aug 27, 2018

    @ansyral
    Xuan Zhou (ansyral)
    on Aug 27, 2018
    Collaborator

    Juliano (@julianosam) I see, for this case we'd better to add a check whether a file is test file before updating codelens. Thanks again for your prompt response.

  12. Xuan Zhou (ansyral)
    assigned
    Sheng Chen (jdneo)
    on Aug 31, 2018

  13. jdneo commented on Sep 3, 2018

    @jdneo
    Sheng Chen (jdneo)
    on Sep 3, 2018
    Member

    Hi Juliano (@julianosam),

    I'm trying to investigate this issue on my side but currently having no luck to reproduce it. May I ask if it is possible for you to provide a sample project that can reproduce this issue on your side?

    Thanks,

  14. julianosam commented on Sep 9, 2018

    @julianosam
    Juliano (julianosam)
    on Sep 9, 2018

    Sheng Chen (@jdneo) Yes. I put together a Spring Boot project for us. I added some instructions how to reproduce in the source file itself. The issue seems to require a combination of Lombok annotations added to a class and the right timing when saving changes to the source file. If the change is saved while the validations are still running, the code completion and validation stops working completely, and can only be fixed by restarting VSCode.

    Let me know your findings!
    https://github.com/julianosam/vscode-test-issue/blob/master/src/main/java/com/vscode/test/issue/vscodetestissue/Lombok.java

  15. jdneo commented on Sep 9, 2018

    @jdneo
    Sheng Chen (jdneo)
    on Sep 9, 2018
    Member

    Juliano (@julianosam) Thank you for the information. I'll look into it!

  16. yaohaizh commented on Sep 12, 2018

    @yaohaizh
    Yaohai Zheng (yaohaizh)
    on Sep 12, 2018
    Contributor

    Wait for this to release: redhat-developer/vscode-java#637 (review)

  17. Rome Li (akaroml)
    added
    in progress
    on Sep 20, 2018
  18. Sheng Chen (jdneo)
    closed this as completedin #309on Sep 20, 2018
  19. Rome Li (akaroml)
    removed
    in progress
    on Sep 20, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions