ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Charles Duffy <char...@dyfis.net>
Subject Re: Re: OverlappingFileLockException when using artifact-lock-nio
Date Thu, 19 Dec 2013 22:36:57 GMT
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.Pfeiffer@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.Pfeiffer@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 <charles@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.Pfeiffer@gebit.de> wrote:
>
> > Cool, if you find something, I'll happily test that.
> >
> > Thanks,
> > Carsten
> >
> >
> >
> > Von:    Charles Duffy <charles@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.Pfeiffer@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
> >
> >
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message