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 > >
