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

Tooling API spawning 'runaway' daemon?

    Details

    • Type: Bug
    • Status: Resolved
    • Resolution: Won't Fix
    • 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 -

        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!
        Hide
        bmuschko Benjamin Muschko added a comment -

        Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved.

        Show
        bmuschko Benjamin Muschko added a comment - Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved.

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Development