Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

option to let the language-server timeout->close #540

Open
GitMensch opened this issue Jun 29, 2021 · 4 comments
Open

option to let the language-server timeout->close #540

GitMensch opened this issue Jun 29, 2021 · 4 comments
Labels
enhancement New feature or request

Comments

@GitMensch
Copy link
Contributor

The language server is automatically started by the extension as soon as a file with a handled language-identifier is opened.
Within the vscode session only one language server is used.

The issue: often vscode stays open for very long time, but the XML file may be directly closed after it is opened - but the language server will stay open.

I suggest to have a configurable timeout in seconds (0 means never); it would be reset as soon as there is communication with the language server and once reached the language server will be closed, possibly only if the current active editor is not one of the file-types handled.

Note sure if this is common but I have multiple instances of vscode running (different workspaces) and to handle bigger files from time to time I have increased the language server's -Xmx vm args and the language server processes - often only needed for 1 to 3 minutes seem to stay open until I let vscode reload the window.

@rgrunber rgrunber added the enhancement New feature or request label Jun 29, 2021
@rgrunber
Copy link
Member

rgrunber commented Jun 29, 2021

Ideally, we would do this by counting the number of xml/xsd/dtd related documents opened on the client side and simply request a shutdown of the language server when that count reaches 0. There should be a preference enabling this, that is disabled by default.

It might be good to get an idea of what the overhead is for starting the language server from scratch since users choosing this option won't benefit from opening a file and having the server already up. Admittedly, I don't think the overhead is bad at all.

Currently we have a bit of a workaround to terminate the language server process (eclipse/lemminx#1070) due to a regression in the language client API, so I'd prefer to implement such a feature once that is sorted out.

@GitMensch
Copy link
Contributor Author

I think there are both use cases:

  • all previously opened editors are closed (increment for new files sent to the language server, decrement when closed) [there may be still multiple editor windows with handled languages "open" - but if they were not active in the current session this doesn't matter]
  • timeout happens; reasoning: some users have a lot of editors "open" and switch between some of them (or just have them open for the next day) but never open those in the current session again, or even minimize vscode for three hours - there's no use in the language server running then

I think it would be good to have two settings for "stop the language server ..." - one is a boolean "when all handled files closed", the other a numeric one "after a timeout of N seconds (0=disabled)".

@GitMensch
Copy link
Contributor Author

@rgrunber just a ping as every related issues are fixed now

@GitMensch
Copy link
Contributor Author

and a friendly pong

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants