What to do about "Gradle Daemon stays open after Eclipse shuts down"?

Old Forum Archive
1

This issue just got raised against the STS gradle tooling: https://issuetracker.springsource.com/browse/STS-3037

I’m not sure how to proceed. I personally think it would be best and logical if the daemon(s) started by STS via tooling API would go away after the STS process itself is terminated.

Alternatively, the tooling API could provide a daemon management API that allows the ‘client’ to explicitly control the lifetime of the deamons that get started on its behalf, so it can attempt to clean-up after itself and terminate these daemons before it exits.

I could also imagine that the whole design of tooling API and daemon really does’t jive with the idea of a tooling API client ‘owning’ a daemon process or controlling its lifetime. Then the best I can do is probably simply provide a way for STS users to configure the deamon timeout value via a preferences page.

Any thoughts on these three options (or some other ideas I haven’t thought of yet)?

Kris

2

Hey Kris,

Thanks for reporting! We’ll discuss this issue with the team. I’m sure we want to fix this problem.

3

Hi Szczepan, is there a JIRA ticket that tracks this issue?

4

Exported to jira. We’ll definitely want to fix this problem at some point.

5

This clears up why with each executing of jettyRunWar/jettyStop I was getting 2 additional unresponsive jvms in process list. It only happens when I do so from STS, but works perfectly from command prompt.

6

Sergei… Right, because on command line by default Gradle isn’t using the gradle daemon.