[VSCODE] Connection got disposed.

[dickydewantoro]

Environment

• Operating System: Windows
• JDK version: 1.8
• Visual Studio Code version: 1.65.2
• Java extension version: 1.4.0

[Carson-yy]

This problem has always existed

[snjeza]

You can try to set the following property:

"java.server.launchMode": "Standard",

[Eskibear]

This "error" is always reported when standard LS is ready and lightweight LS is killed. IMO it's not an "error" but an expected message. I do see a lot of same message in client.log as below, which sometimes affects the diagnosis.

{
  message: '[Error - 13:31:54] Connection to server got closed. Server will not be restarted.',
  level: 'info',
  timestamp: '2022-03-21 13:31:54.695'
}

I prefer to do both:

• Figure out how to stop reporting this error if it's an expected behavior.
• Save logs related to lightweight LS into another file, in order not to mix with those related to standard server.

WDYT?

[testforstephen]

Figure out how to stop reporting this error if it's an expected behavior.

It should avoid such error by adding a try ... catch when stopping lightweight LS. https://github.com/redhat-developer/vscode-java/blob/7ed079860ac01d35099021f55d7139718b3fe9fe/src/syntaxLanguageClient.ts#L89-L95

[Eskibear]

My stupid question is, why does languageClient.stop() throw this error? Has lightweight LS stopped itself before we call languageClient.stop()? Anyway to check if the connection already get disposed? Or we simply try-catch it..

[rgrunber]

I would probably check if this is related to https://github.com/redhat-developer/vscode-java/issues/1928 .

There has been a long standing bug with vscode-languageserver-node where the shutdown/exit sequence doesn't happen correctly. The error is annoying, but doesn't result in any lack of functionality. Initially I tried to ensure the LS exits immediately after the shutdown is sent to the LS, which I believe also prevented the write errors from being logged. Is something on the client-side using the connection without knowing it has been disposed, or maybe from other parts of the vscode-languageserver-node API.

This should be fixed in 3.17, though I was hoping they would have released a 3.16.1 by now.