Gradle
  1. Gradle
  2. GRADLE-2228

Tooling API: Avoid unnecessary daemon processes creation

    Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Resolution: Fixed
    • Affects Version/s: 1.0-rc-1
    • Fix Version/s: 1.1-rc-1

      Description

      One of the IntelliJ IDEA gradle integration users reported that new gradle daemon process is spawned every time the gradle api is asked to resolve the project (execute org.gradle.tooling.ModelBuilder.get()).

      Please define what information should be provided in order to sort the problem out

      1. daemon-3865.out.log
        11 kB
        Ryan Stewart
      2. daemon-4047.out.log
        11 kB
        Ryan Stewart
      3. daemon-4152.out.log
        11 kB
        Ryan Stewart
      4. idea.log
        303 kB
        Beenish Zaidi
      5. intellij-gradle-verbose-logs.tar.gz
        392 kB
        Ryan Stewart

        Activity

        Hide
        Szczepan Faber
        added a comment -

        For my sanity, can you confirm that the Gradle version the JetGradle uses is at least 1.1? JetGradle does not respect GRADLE_HOME from the env AFAIK (and I don't think it should). There's UI configuration for it in JetGradle.

        JetGradle does not respect the Gradle wrapper setting, too, which is unfortunate, but I'm hoping it will get fixed in JetGradle at some point (please vote for this ticket in the JetGradle tracker .

        Tooling api does fork a new daemon if the current one is busy. Rapidly clicking refresh causes extra daemons for that reason I think.

        Tooling api does not implement any synchronization rules (other than most clases are designed to be thread-safe - see the javadoc for more details). If users request multiple operations concurrently the tooling API will attempt to execute them concurrently. At the moment we don't plan to change that behavior in the tooling api.

        It's up to the client to synchronize the operations that should not execute concurrently. For example, I think JetGradle should not allow multiple concurrent entire-project refreshes. Yet, it should allow running tasks concurrently (for example when the user wants to run :a:foo and :b:bar concurrently).

        Show
        Szczepan Faber
        added a comment - For my sanity, can you confirm that the Gradle version the JetGradle uses is at least 1.1? JetGradle does not respect GRADLE_HOME from the env AFAIK (and I don't think it should). There's UI configuration for it in JetGradle. JetGradle does not respect the Gradle wrapper setting, too, which is unfortunate, but I'm hoping it will get fixed in JetGradle at some point (please vote for this ticket in the JetGradle tracker . Tooling api does fork a new daemon if the current one is busy. Rapidly clicking refresh causes extra daemons for that reason I think. Tooling api does not implement any synchronization rules (other than most clases are designed to be thread-safe - see the javadoc for more details). If users request multiple operations concurrently the tooling API will attempt to execute them concurrently. At the moment we don't plan to change that behavior in the tooling api. It's up to the client to synchronize the operations that should not execute concurrently. For example, I think JetGradle should not allow multiple concurrent entire-project refreshes. Yet, it should allow running tasks concurrently (for example when the user wants to run :a:foo and :b:bar concurrently).
        Hide
        Etienne Studer
        added a comment -

        I'm on 1.2. To me, too, this seems more like an IDEA issue than a Gradle issue.

        Show
        Etienne Studer
        added a comment - I'm on 1.2. To me, too, this seems more like an IDEA issue than a Gradle issue.
        Hide
        Jayson Minard
        added a comment -

        Yes, 1.2. My above settings work around the issues with lining up the JAVA_HOME directories used by everything; which causes multiple daemon processes if they are not identical. The rest are just logic issues with IntelliJ's use of the tooling API, maybe...

        I'll drop a note over in their tracker.

        Show
        Jayson Minard
        added a comment - Yes, 1.2. My above settings work around the issues with lining up the JAVA_HOME directories used by everything; which causes multiple daemon processes if they are not identical. The rest are just logic issues with IntelliJ's use of the tooling API, maybe... I'll drop a note over in their tracker.
        Hide
        Jayson Minard
        added a comment -

        I commented on both of the old IntelliJ bug reports IDEA-84443 and IDEA-88068 ... and created this one specifically for concurrent refreshes: IDEA-92954

        Show
        Jayson Minard
        added a comment - I commented on both of the old IntelliJ bug reports IDEA-84443 and IDEA-88068 ... and created this one specifically for concurrent refreshes: IDEA-92954
        Hide
        Szczepan Faber
        added a comment -

        Thanks a lot!!! It is really helpful if JetGradle receives reports from our users, not only from us - Gradle devs.

        Show
        Szczepan Faber
        added a comment - Thanks a lot!!! It is really helpful if JetGradle receives reports from our users, not only from us - Gradle devs.

          People

          • Assignee:
            Szczepan Faber
            Reporter:
            Denis Zhdanov
          • Votes:
            5 Vote for this issue
            Watchers:
            7 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: