Quiting vscode-metals keeps still one java process

[maciejbak85]

Try to open Vscode + metals, work a bit, then quit vscode.
One Java process is still running in the system, and will run forever.

Java process should be quit as well

here is the screenshot:
https://imgur.com/a/7nJg3IY

• Operating system: macOS
• VSCode version: 1.41.1
• Metals version: 1.7.7

[tgodzik]

Thanks for reporting! Is this a Metals process or Bloop? There should be more info in the name.

Bloop is a build server and we share it between instances, so it is not killed automatically when quiting VS Code. Especially that it can be used from CLI as well.

[maciejbak85]

@tgodzik hmm looks like bloop:

https://pastebin.com/65ruh3iB

[maciejbak85]

but if its a bloop, then question: do I need to kill it always by myself ? this bloop hanging there is the one that is automatically run by vscode. I am not starting it by my self.

[olafurpg]

@maciejbak85 thank you for reporting! This is working as expected, the Bloop process is supposed to continue running after Metals exits. The Bloop process is reused between multiple Metals servers if you're for example working on multiple projects.

Is this process causing problems? I'm open to discuss options for how we could automatically shut down the Bloop server when there is no active Metals client. This process does consume memory, which I understand may be undesirable. Maybe we could extend Bloop to turn itself off if there are no requests after some timeout 🤔

[maciejbak85]

Maybe we could extend Bloop to turn itself off if there are no requests after some timeout
thats good idea.

ok thanks for the info, at least I know that it is expected behaviour :)

[vasilmkd]

Yes, turning the server off automatically (by default after a period of inactivity, or configurably when there are no more connected clients) would be very desirable as it is quite a heavy process, often consuming over 2 Gb of memory.

[tgodzik]

@jvican what do you think about adding a timeout to Bloop, would that be sensible? We could have it as an additional property, which would be set when running from Metals.

Though most likely it should be specified explicitly by the user.

[tgodzik]

Closing this, as automatically shutting down Bloop is not something that we will likely support. It is optimized for users doing Scala daily and having a single Bloop server means we can have a lot of different workspaces with a limited amount of memory used. To optimize it further you can use ~/.bloop/.jvmopts.

We should soon be able to run coursier install bloop to install Bloop in Metals, the CLI will be accessible so that users can do bloop exit in case they don't want to have it running anymore.

[cbrunnkvist]

This is a feature, not a bug? scalameta/metals-feature-requests/issues/147

It would be nice if it featured some kind of "apoptosis" and would just exit without fuss if left unused for N minutes or something.

[tgodzik]

@cbrunnkvist the purpose of Bloop is to provide compilation for more than one workspace, which is why it's kept alive between Metals sessions. We could probably try to work on some auto shutdown for Bloop if the workspace is not used for a longer time. This is however unclear what delay we should have.

[andyczerwonka]

In my case, that process is 10G of memory, so not idea keeping it around.

[ivan-brko]

I also have issues when this process keeps hanging even after I stop working on Scala project and start working on something different. Could this be some sort of configuration option? If you want it to keep running or shut down after some timeout?

[ghost]

This is totally unacceptable default behavior. If Metals starts the process then it should kill it at shut down, no discussion! Leaving Java processes hanging around just in case it may be needed again later is counter-intuitive and could at best be acceptable as an option. The general user does not need this and will not see restarting the process for subsequent Metals use as a problem.
I have been using VSCode+Metals for a couple of months now and thought this was a bug. Having to open a terminal and kill the process manually each time has been a pain. Knowing this was done intentionally makes it intolerable. Change this! Please.

[tgodzik]

This is totally unacceptable default behavior. If Metals starts the process then it should kill it at shut down, no discussion!

Having to open a terminal and kill the process manually each time has been a pain. Knowing this was done intentionally makes it intolerable. Change this! Please.

Thanks for the comment, however I would ask you keep your comments more friendly and productive. Contributors are more likely to respond if you do so. This is an open source project with a lot of different people involved and there certainly needs to be a discussion, since this is not as simple. We keep this process alive to be used by different workspaces and also to make sure the compile is hot (JITted) to provide the best experience possible.

Instead of what you wrote you could write something like:

It would be better if the Metals shuts down the background Java server as I need to close the server manually and i has been a chore for me.

There is a feature request that you might be interested in:

scalameta/metals-feature-requests#129

It can be voted on to make sure we take care of it first.

[ghost]

Sorry if my remark sounds unfriendly, it was not meant to be. I found this by Googling the issue. Since others did put this more subtly and the issue was then closed as wont-fix I intended to be a bit more explicit. Please note that I do appreciate all the work that people are putting into this and do not want to offend anyone. I will vote for the other issue.