Workspace hanging on re-build

[dsyer]

I left it over night. Killed it. Started again. Still the same.

threads.txt

[martinlippert]

So starting up STS4, workspace re-build kicks in, but hangs forever?!? Can you do anything at all after starting up STS4 ?

[dsyer]

Can you do anything at all after starting up STS4 ?

The UI is responsive up to a point. As soon as I try to open a closed project or delete a file or anything it brings up the "Waiting for ... " dialog and I just see "Building workspace..." forever.

[martinlippert]

What happens if you disable the Spring Boot Language Server in the preferences? There is a preference for all Language Servers where you can uncheck the Spring Boot one for Java source and property files. Can you try that? Just would like to see if this is related to the hang.

[kdvolder]

Took a peek at the stacks. Almost every thread is waiting for a lock. The only thread that is 'inside' some locks is the one sending classpath data to the language server. I think if, for some reason, the language server were stuck and not responsive to process this request, that could explain why everything is stuck.

It would be interesting to see what the stacks look like on the other side of the connection (i.e. the language server process that should be receiving the classpath data).

[martinlippert]

While working on unblocking some synchronization in the language server, I came across this again. Many things have changed since then and I don't think we will end up in this situation again anytime soon. But I've seen this in the thread dump that concerns me a bit:

"Worker-8: Building workspace" #46 prio=5 os_prio=0 tid=0x00007f7a24001000 nid=0x39bf waiting for monitor entry [0x00007f7a2bffd000]
   java.lang.Thread.State: BLOCKED (on object monitor)
	at org.eclipse.lsp4j.jsonrpc.json.StreamMessageConsumer.consume(StreamMessageConsumer.java:66)
	- waiting to lock <0x00000000b8cf3ed0> (a java.lang.Object)
	at org.eclipse.lsp4e.LanguageServerWrapper.lambda$1(LanguageServerWrapper.java:215)
	at org.eclipse.lsp4e.LanguageServerWrapper$$Lambda$413/146650700.consume(Unknown Source)
	at org.eclipse.lsp4j.jsonrpc.RemoteEndpoint.notify(RemoteEndpoint.java:126)
	at org.eclipse.lsp4j.jsonrpc.services.EndpointProxy.invoke(EndpointProxy.java:88)
	at com.sun.proxy.$Proxy43.didChangeWatchedFiles(Unknown Source)
	at org.springframework.tooling.boot.ls.ResourceListener.sendFileEvents(ResourceListener.java:61)
	at org.springframework.tooling.boot.ls.ResourceListener.resourceChanged(ResourceListener.java:55)
	at org.eclipse.core.internal.events.NotificationManager$1.run(NotificationManager.java:300)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
	at org.eclipse.core.internal.events.NotificationManager.notify(NotificationManager.java:290)
	at org.eclipse.core.internal.events.NotificationManager.broadcastChanges(NotificationManager.java:153)
	at org.eclipse.core.internal.resources.Workspace.broadcastPostChange(Workspace.java:379)
	at org.eclipse.core.internal.resources.Workspace.endOperation(Workspace.java:1502)
	at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:160)
	at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:235)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)

This refers to a call to the language servers (to notify them of changes) as a sync call within the workspace build job. So if a language server listens for those changes, but is not responding well or receiving this event quickly enough, it might block the workspace build.

Therefore keeping this open for further investigation in this area.

[martinlippert]

I am closing this one here due to no activity since Feb 21. If you come across this again, please comment and we can re-open anytime.