You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
(substitute your home to ~, otherwise sbt doesn't understand it)
Wait for the output:
[info] server was not detected. starting an instance
[warn] server is started using sbt-launch jar directly
[warn] this is not the recommended way: .sbtopts and .jvmopts files are not loaded and SBT_OPTS is ignored
[warn] either upgrade sbt.bat to its latest version or make sure it is accessible from $PATH, and run 'sbt bspConfig'
[info] welcome to sbt 1.8.0 (Amazon.com Inc. Java 18.0.2)
[info] loading global plugins from C:\Users\dmitrii.naumenko\.sbt\1.0\plugins
[info] loading project definition from C:\Users\dmitrii.naumenko\project
[info] set current project to dmitrii-naumenko (in build file:/C:/Users/dmitrii.naumenko/)
[info] sbt server started at local:sbt-server-3c9af2a7955490544b47
[info] started sbt server
Notice that two processes are launched:
The first corresponds to the JVM we just launched
Second, it's child:
Actual result
The child process isn't terminated, it remains hanging.
You need to kill it via process explorer.
Expected result
I am not that experienced in BSP but to me, it seems like a strange, not practical default behavior.
If after starting the main process it doesn't quit immediately I would expect that killing it would also kill the child server process.
While trying to debug various issues with IntelliJ-BSP integration I constantly had to kill processes from process explorer dozens of times.
What's more - AFAIU there is no way to disable this behavior because --detach-stdio is hard-coded in sbt.internal.client.NetworkClient#waitForServer and the comment says:
This instance must be shutdown explicitly via sbt -client shutdown
But this also doesn't work: #6723
It would be nice if the default behavior killed the child sbt server process
Thanks for the report.
This is somewhat complicated topic, but one motivation of having the sbt server in general is to speed up the perceived load time by having the server always running. This allows interaction via sbtn client from shell issueing one command at a time.
I think there's a setting somewhere to control the idle TTL (time to live). I wonder if that should be set to 0s for BSP?
@eed3si9n
I would like to clarify some points, including terminology, just to be on the same page in the future.
As I mentioned, when I start the process ("process1") from a command line generated in .bsp/sbt.json (with xsbt.boot.Boot -bsp) it forks a child process ("process2", with --detach-stdio --server).
What are the correct terms for both of the processes?
AFAIU "process2" is at the same time a BSP server and SBT server:
I can connect to it via sbtn --client and send sbt commands.
At the same time I can connect to it via BSP client (e.g. from IntelliJ)
Is that correct?
If so, then what is then "process1" for?
Can't we skip forking another process and just start the combined SBT/BSP server in the original process when passing -bsp?
Or if the proper command to start BSP server is just --detach-stdio --server can we use it directly in .bsp/sbt.json?
(I am on Windows)
(substitute your home to
~
, otherwise sbt doesn't understand it)Notice that two processes are launched:
The first corresponds to the JVM we just launched
Second, it's child:
Ctrl + C
Actual result
The child process isn't terminated, it remains hanging.
You need to kill it via process explorer.
Expected result
I am not that experienced in BSP but to me, it seems like a strange, not practical default behavior.
If after starting the main process it doesn't quit immediately I would expect that killing it would also kill the child server process.
While trying to debug various issues with IntelliJ-BSP integration I constantly had to kill processes from process explorer dozens of times.
What's more - AFAIU there is no way to disable this behavior because
--detach-stdio
is hard-coded insbt.internal.client.NetworkClient#waitForServer
and the comment says:It would be nice if the default behavior killed the child sbt server process
cc @jastice
The text was updated successfully, but these errors were encountered: