Hi Charles, awesome, your fix works perfectly. That was fast :-)
Thanks a lot, Carsten Von: Charles Duffy <char...@dyfis.net> An: Ant Developers List <dev@ant.apache.org> Datum: 19.12.2013 23:37 Betreff: Re: Re: OverlappingFileLockException when using artifact-lock-nio Howdy, Carsten -- Thank you again for the reproducer, which was invaluable in tracking down this issue and validating the fix. The issue should be resolved in current trunk; also, a new test case has been added to the suite to prevent regressions. Please let me know if you have further issues. Thanks, -- Charles On Wed, Dec 18, 2013 at 3:16 AM, <carsten.pfeif...@gebit.de> wrote: > Hi again, > > I've filed the issue https://issues.apache.org/jira/browse/IVY-1454 > The exception indeed appears to occur due to our specific use of > the parallel task, in conjunction with the antcallback task from > ant-contrib. > > Thanks, > Carsten > > > > Von: carsten.pfeif...@gebit.de > An: "Ant Developers List" <dev@ant.apache.org> > Datum: 18.12.2013 09:38 > Betreff: Re: OverlappingFileLockException when using > artifact-lock-nio > > > > Hi Charles, > > thanks a lot for your investigation -- I'm gathering some more information > > about the problem > and submit them to JIRA. The is a trunk build from > https://builds.apache.org/job/Ivy/446/ and > unfortunately, we're not using symlinks to the caches and have multiple > cache configurations :-} > > I'll send a notice with the issue number when I've got all the details. > > Thanks, > Carsten > > > > Von: Charles Duffy <char...@dyfis.net> > An: Ant Developers List <dev@ant.apache.org> > Datum: 18.12.2013 01:49 > Betreff: Re: Re: OverlappingFileLockException when using > artifact-lock-nio > > > > Howdy -- > > I've spent a few minutes analyzing the logic in the code in question. > > tryLock is documented to throw that exception only when the other instance > of the lock is held by the same process, rather than by out-of-process > code. > > The current code intends to avoid that situation by use of a synchronized > block in acquireLock(); tryLock() is only called within that block. Since > the concrete lock strategy classes' instances should be singletons, that > block should prevent multiple tryLock() invocations inside a process. > > Unfortunately, the practice appears to differ from that theory, but even > so, a few conclusions can be drawn: > > - The issue in question should be specific to use of <parallel>, not to > multiple uses of ivy from unrelated JVM processes. > - The underlying issue extends beyond the NIO locker -- I wouldn't trust > either of Ivy's file-locking mechanisms to be safe if the intended > synchronization guarantee by acquireLock() is invalid. > - If there's any chance you could have multiple definitions of the same > cache in your configuration, particularly with different filenames > referring to the same files (as with symlinks), that would make this much > less of a puzzle. :) > > Could you confirm that you can reproduce this on a trunk build of Ivy? > (NIO > locking was very, very broken prior to the merge of IVY-1424). > > To come closer to a proper fix, I'll need to put together a reproducer. > Have you filed a JIRA ticket for this (on > https://issues.apache.org/jira/browse/IVY), or would you like me to do so > on your behalf? > > Thanks! > > > On Tue, Dec 17, 2013 at 10:29 AM, <carsten.pfeif...@gebit.de> wrote: > > > Cool, if you find something, I'll happily test that. > > > > Thanks, > > Carsten > > > > > > > > Von: Charles Duffy <char...@dyfis.net> > > An: Ant Developers List <dev@ant.apache.org> > > Datum: 17.12.2013 15:29 > > Betreff: Re: OverlappingFileLockException when using > > artifact-lock-nio > > > > > > > > I'll try to take a look at this today. Thanks for the report! > > > > > > On Tue, Dec 17, 2013 at 8:19 AM, <carsten.pfeif...@gebit.de> wrote: > > > > > Hi, > > > > > > I just tried the artifact-lock-io lockstrategy with > > > ivy_2.4.0.alpha_20131214174343.jar. > > > At some point I got resolve error like this: > > > > > > [ivy:resolve] :::::::::::::::::::::::::::::::::::::::::::::: > > > [ivy:resolve] :: UNRESOLVED DEPENDENCIES :: > > > [ivy:resolve] :::::::::::::::::::::::::::::::::::::::::::::: > > > [ivy:resolve] :: org.hamcrest#hamcrest-core;1.1: > > > java.nio.channels.OverlappingFileLockException at > > > sun.nio.ch.SharedFileLockTable.checkList(FileLockTable.java:255) > > > [ivy:resolve] :: org.glassfish#javax.ejb;3.1: > > > java.nio.channels.OverlappingFileLockException at > > > sun.nio.ch.SharedFileLockTable.checkList(FileLockTable.java:255) > > > [ivy:resolve] :: > org.jboss.weld.se#weld-se-core;1.1.10.Final: > > > java.nio.channels.OverlappingFileLockException at > > > sun.nio.ch.SharedFileLockTable.checkList(FileLockTable.java:255) > > > [ivy:resolve] :::::::::::::::::::::::::::::::::::::::::::::: > > > > > > Now I'm wondering if I did something wrong in our <parallel> tasks or > if > > > that rather indicates > > > a problem in the lock strategy implementation. > > > > > > The build system is Debian Linux (Wheezy), filesystem is local. > There's > > no > > > other access to > > > Ivy's cache than by Ivy itself. > > > > > > Best regards > > > Carsten > > > > > > >
