Uploaded image for project: 'Gradle'
  1. Gradle
  2. GRADLE-1594

Tooling API spawning 'runaway' daemon?

    Details

    • Type: Bug
    • Status: Open
    • Resolution: Unresolved
    • Affects Version/s: 1.0-milestone-3
    • Fix Version/s: None

      Description

      When I run some Gradle action/command (doesn't really matter what) from STS (uses the Gradle tooling API milestone-3) it starts an external process (I'm assuming this is a gradle daemon).

      Sometimes this process gets busy with a very long running operation. If I try to exit Eclipse/STS it won't let me until this operation is finished. It is then very tempting to forcibly kill Eclipse/STS.

      Unfortunately, when you do that the Daemon is left running and I don't think there's a way for me to shut it down (except kill it using a kill command on in the os commandline) "kill -9 <process-id>"

      I also tried running "gradle --stop" on the commandline but the process was left running (and it is telling me the Daemon isn't running).

        Activity

        Hide
        kdvolder Kris De Volder added a comment -

        The third daemon that just got started, aparantly also isn't running:

        kdvolder@bun2:~/commandline-dev/gradle-plugins$ gradle --stop
        Gradle daemon is not running.
        

        This is odd, because it just succesfully built a gradle model for my STS.

        Show
        kdvolder Kris De Volder added a comment - The third daemon that just got started, aparantly also isn't running: kdvolder@bun2:~/commandline-dev/gradle-plugins$ gradle --stop Gradle daemon is not running. This is odd, because it just succesfully built a gradle model for my STS.
        Hide
        kdvolder Kris De Volder added a comment -

        Some positive news:

        I tried the following:

        • start STS
        • start executing a gradle command
        • kill STS while the command is running

        => it looks like the daemon executing this command is immediately terminated.

        So I am no longer able to get into a situation where I accumulate dead daemons by killing processes that are using the daemon "in midflight".

        Show
        kdvolder Kris De Volder added a comment - Some positive news: I tried the following: start STS start executing a gradle command kill STS while the command is running => it looks like the daemon executing this command is immediately terminated. So I am no longer able to get into a situation where I accumulate dead daemons by killing processes that are using the daemon "in midflight".
        Hide
        adammurdoch Adam Murdoch added a comment - - edited

        @Kris, thanks for this feedback. It's excellent stuff. Given what you've seen, let's leave this issue open.

        I've raised some other issues based on what you've mentioned:

        GRADLE-1890 - don't leave more than one idle daemon running.
        GRADLE-1891 - consider daemons from all Gradle versions for daemon management (timeouts and gradle --stop, etc).

        Then there's:

        GRADLE-1771/GRADLE-1240 - to reduce the memory impact of each daemon instance.
        GRADLE-1763 - daemon management should deal with ~/.gradle being deleted.

        Our plan is to fix 1890, 1771/1240 and 1765 fairly soon. We're holding off on 1891 for a bit, until the client - daemon protocol stabilises a little.

        Show
        adammurdoch Adam Murdoch added a comment - - edited @Kris, thanks for this feedback. It's excellent stuff. Given what you've seen, let's leave this issue open. I've raised some other issues based on what you've mentioned: GRADLE-1890 - don't leave more than one idle daemon running. GRADLE-1891 - consider daemons from all Gradle versions for daemon management (timeouts and gradle --stop, etc). Then there's: GRADLE-1771 / GRADLE-1240 - to reduce the memory impact of each daemon instance. GRADLE-1763 - daemon management should deal with ~/.gradle being deleted. Our plan is to fix 1890, 1771/1240 and 1765 fairly soon. We're holding off on 1891 for a bit, until the client - daemon protocol stabilises a little.
        Hide
        kdvolder Kris De Volder added a comment -

        Sounds good. I also hope you'll consider a more reasonable timeout... 3 hours seems a bit long

        Another thing worth considering is that my point of view is that of an interactive user who 'owns' the machine he's using.

        Things may be different if you consider scenarios of running builds on something like a shared build server.

        Show
        kdvolder Kris De Volder added a comment - Sounds good. I also hope you'll consider a more reasonable timeout... 3 hours seems a bit long Another thing worth considering is that my point of view is that of an interactive user who 'owns' the machine he's using. Things may be different if you consider scenarios of running builds on something like a shared build server.
        Hide
        bmuschko Benjamin Muschko added a comment -

        As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

        We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

        Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

        • Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
        • Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

        We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

        Show
        bmuschko Benjamin Muschko added a comment - As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub. We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to. Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by: Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines . Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete. We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

          People

          • Assignee:
            Unassigned
            Reporter:
            kdvolder Kris De Volder
          • Votes:
            3 Vote for this issue
            Watchers:
            6 Start watching this issue

            Dates

            • Created:
              Updated:

              Development