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

Tooling API should provide cancelation for long running operations

    Details

    • Type: Improvement
    • Status: Resolved
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.1-rc-1

      Description

      With some Gradle operations taking over 10 minutes to run, cancelation is very important.

      In the present condition, it is often impossible to gracefully even just shutdown Eclipse without waiting for several minutes for some pending background Gradle task to complete. (A pity really since, if the next thing is shutting down Eclipse, the work done by these tasks is really not needed anymore).

      Since there is no API for canceling tasks or model build requests, the cancel button in Eclipse do not work, nor does Eclipse have any way of shutting down tasks prematurely if the result of the task is no longer required (such as when shutting down Eclipse).

      This is all potentially very frustrating to users. Often the only way to deal with these hangups is to kill the entire Eclipse process.

        Activity

        Hide
        kelemen Attila Kelemen added a comment -

        This is my number one request as well. I would also add, that cancellation is not just important because a task might take too long to execute but if executing the main class of a project is done through a Gradle task, it is important to allow the task to be canceled (and the forked process to be killed) because the code might be buggy and there is no other way to stop it. Also there can be multiple java processes running (including the Gradle daemon) and choosing which to kill is not trivial.

        Show
        kelemen Attila Kelemen added a comment - This is my number one request as well. I would also add, that cancellation is not just important because a task might take too long to execute but if executing the main class of a project is done through a Gradle task, it is important to allow the task to be canceled (and the forked process to be killed) because the code might be buggy and there is no other way to stop it. Also there can be multiple java processes running (including the Gradle daemon) and choosing which to kill is not trivial.
        Hide
        basiliscus Vasily Karyaev added a comment -

        Is there any chance this issue will be resolved within the next 6 months (at least)?

        It seems like a design flaw to me.
        The issue affects not only the long running operations, but regular builds too. In large and complex projects the builds may take minutes to complete. It is a frequent situation when developers change their mind and decide to stop the build. Going to the command line prompt, searching for the processes and killing them is a real pain, apparently.

        Show
        basiliscus Vasily Karyaev added a comment - Is there any chance this issue will be resolved within the next 6 months (at least)? It seems like a design flaw to me. The issue affects not only the long running operations, but regular builds too. In large and complex projects the builds may take minutes to complete. It is a frequent situation when developers change their mind and decide to stop the build. Going to the command line prompt, searching for the processes and killing them is a real pain, apparently.
        Hide
        szczepiq Szczepan Faber added a comment -

        Thanks guys for feedback. We'll take it into account during the next prioritization session. I say that there is a good chance it will be solved in the next 6 months.

        Show
        szczepiq Szczepan Faber added a comment - Thanks guys for feedback. We'll take it into account during the next prioritization session. I say that there is a good chance it will be solved in the next 6 months.
        Hide
        jin Jin Chai added a comment -

        It is the number one for me. It will be very frustrating to kill eclipse every time when the task hangs especially if you have JavaExec task to start long running process.

        Show
        jin Jin Chai added a comment - It is the number one for me. It will be very frustrating to kill eclipse every time when the task hangs especially if you have JavaExec task to start long running process.
        Hide
        pron Ron Pressler added a comment -

        With Gradle gaining momentum, more and more IDEs integrate with it, and are expected to integrate well. Not being able to cancel a build, or, more importantly (as Attila said), a run, is a detriment to high quality IDE integration expected from a popular build tool.

        Show
        pron Ron Pressler added a comment - With Gradle gaining momentum, more and more IDEs integrate with it, and are expected to integrate well. Not being able to cancel a build, or, more importantly (as Attila said), a run, is a detriment to high quality IDE integration expected from a popular build tool.
        Hide
        shevek Shevek added a comment -

        Please, please fix this bug. I love gradle, I expect to use it for all my projects henceforth, but just launching a job and being unable to kill it (e.g. a test case which hung/looped) is a major weakness in gradle's IDE integration. I vote heavily for this bug. Thank you.

        Show
        shevek Shevek added a comment - Please, please fix this bug. I love gradle, I expect to use it for all my projects henceforth, but just launching a job and being unable to kill it (e.g. a test case which hung/looped) is a major weakness in gradle's IDE integration. I vote heavily for this bug. Thank you.
        Hide
        wolpers Thorsten Schemm added a comment -

        I have been wondering if there might be a workaround to this issue. Since the tooling API always uses the daemon process, is there a way to programmatically get the process ID of the daemon process and kill it through platform specific Runtime.exec(..) magic? Lots of folks watching this issue for a while now, maybe someone already found an acceptable workaround?

        Show
        wolpers Thorsten Schemm added a comment - I have been wondering if there might be a workaround to this issue. Since the tooling API always uses the daemon process, is there a way to programmatically get the process ID of the daemon process and kill it through platform specific Runtime.exec(..) magic? Lots of folks watching this issue for a while now, maybe someone already found an acceptable workaround?
        Hide
        radimk Radim Kubacki added a comment -

        Please bear with us a little longer. Exposing internal details and playing with OS specific tools to kill processes is not a preferred way how to address this.

        Show
        radimk Radim Kubacki added a comment - Please bear with us a little longer. Exposing internal details and playing with OS specific tools to kill processes is not a preferred way how to address this.
        Hide
        Eran Samocha Eran Samocha added a comment -

        Any updates on this issue? it's very frustrating

        Show
        Eran Samocha Eran Samocha added a comment - Any updates on this issue? it's very frustrating

          People

          • Assignee:
            radimk Radim Kubacki
            Reporter:
            kdvolder Kris De Volder
          • Votes:
            38 Vote for this issue
            Watchers:
            31 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development