[GRADLE-2415] Daemon holds lock on JARs used in buildscript classpath after build completes Created: 01/Aug/12  Updated: 01/Aug/16  Resolved: 16/May/16

Status: Resolved
Project: Gradle
Affects Version/s: 1.1
Fix Version/s: None

Type: Bug
Reporter: Andrew Oberstar Assignee: Unassigned
Resolution: Fixed Votes: 7

Attachments: Zip Archive daemon-funtest.zip    
Issue Links:
Related
Related to GRADLE-3512 Gradle daemon corrupts resources in s... Resolved
Related to GRADLE-2275 Clean can fail on windows when using ... Resolved

 Description   

We are using the tooling API for functional tests of our plugins. When using the standard behavior (embedded=false) the tooling API uses the daemon to execute the functional tests. Repeated executions (primarily if they call clean) can cause failures due to locks still being held the plugin JAR that we are testing.

I attached a full example of the structure we are using. You can verify the behavior with the following steps:

You will need to to toggle the embedded flag used in the test. (under src/main/groovy)

1. Embedded=true: Run gradle test – should work fine
2. Embedded=true: Run gradle clean test – should work fine
3. Embedded=false: Run gradle clean test – should work fine (first one to use the daemon)
4. Repeat 3 – should fail since daemon from 3 is still holding lock on plugin JAR.

 Comments   
Comment by Andrew Oberstar [ 21/Aug/12 ]

I have noticed this locking when running sonar analysis two builds in a row when using the daemon. Holds a lock on the batch JARs that are downloaded into build/sonar/batch.

Comment by Andrew Oberstar [ 21/Aug/12 ]

Also this is all on Windows 7.

Comment by Andrew Oberstar [ 27/Sep/12 ]

This issue is really holding up my adoption of the daemon for the compatibility tests for our internal plugin build. This results in me being stuck with the embedded connector, which is not only internal, but has caused at least 3 issues with our plugin build.

  • Classpath issues when trying to run the Gradle build with a 1.1+ version of Gradle. (Had to stay with 1.0)
  • Classpath issues when trying to run a Sonar analysis. (had to ignore the test)
  • PermGen space issues. (Was able to work around this by forking the test process and increasing the permgen space)
Comment by Szczepan Faber [ 21/Nov/12 ]

Thanks a lot for reporting! We'll attack this problem with the next batch of daemon fixes.

Comment by Peter Niederwieser [ 21/Jan/13 ]

Cannot reproduce on Mac. Probably Windows specific.

Comment by Andrew Kowal [ 18/Jul/13 ]

Guys,

this issues is reproducible in 1.7-RC-1.

Do you plan to fix it?

Comment by Andrew Oberstar [ 18/Jul/13 ]

Playing around with this example app, I'm still seeing the issue in 1.6.

However, we did get past this for our primary use case. It involved a bunch of changes, so I don't know what ended up fixing it:

  • Upgraded our build to use Gradle 1.2 (Fix in 1.1 for clean task deleteQuietly)
  • Added a `project.close()` in the `@After` for our tests
  • Used system properties to shorten length of time daemons stick around (I think to 10 seconds)

There might have been more, but that's all I can remember off the top of my head.

Comment by Adam Murdoch [ 18/Jul/13 ]

We do plan to fix it. It's a matter of finding the time to do so. We'd welcome a contribution to fix this, if you (or anyone else) is interested in helping out. If so, let us know on the dev mailing list and we can help you get started.

Comment by Jim Moore [ 14/Jul/15 ]

Is this still an issue? Don't have a Windows machine to test, but I do need Windows users on my team to not get bit by this.

Comment by Andrew Oberstar [ 14/Jul/15 ]

From what I remember, this was a somewhat specific use case, executing Gradle builds via the Tooling API in a Test task. As mentioned in 2013, my main example of this doesn't have the issue anymore, and I generally notice less (maybe no) issues like this now.

Comment by Michael Barnathan (Inactive) [ 16/May/16 ]

We are seeing similar issues in other tasks (e.g. GRADLE-2275), but this one appears to be dated. I'm going to close it in favor of tracking the other issues.

Generated at Wed Jun 30 12:21:17 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.