Closed odisseus closed 7 months ago
Hi @odisseus
Regarding running bazel event service in the separate JVM: it might be done for isolation reasons, not to crash the main agent process if something bad happens. But I am not entirely sure here..
Also If i understand correctly you have suggested to run Build Events Service not on the agent, but on the server. As far as I know we do not run any tools on the server side, except cases we can't avoid: when tool execution is needed to trigger new build (when maven package was published for example). Because it will create additional load on the server that might affect experience of all users.
Thank you for the explanation! What I actually had in mind is the possibility to run the event service within the agent plugin, not the server plugin. (Of course it has to work on the agent side, because it needs to launch the Bazel application and monitor the build event file.)
Isolating the consequences of a crash (or memory leak etc.) is a valid concern for third-party code. However, in this particular case, moving part of the code into a separate JVM seems to be a bit of an overkill.
I guess that the more important reason to run the event service in a separate JVM is the call to URL.setURLStreamHandlerFactory
, which is allowed only once per JVM (and has side effects beyond the scope of the current build).
However, there seem to be workarounds for this issue.
I wonder why the code responsible for launching Bazel and listening to its build events is packaged as a separate JAR and launched in a separate JVM. Surely this functionality could be implemented within the ~server~ agent plugin?