Test runners interfere with Java language server

[akaroml]

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.

[ansyral]

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.

[aholstenson]

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.

[julianosam]

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

[ansyral]

Thanks for the info, @aholstenson @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.

[julianosam]

@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?

[julianosam]

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.

[ansyral]

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. @julianosam @aholstenson is this the scenario where you're stuck while editing java files?

[julianosam]

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?

[ansyral]

@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.

[jdneo]

Hi @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,

[julianosam]

@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

[jdneo]

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

[yaohaizh]

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