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 Wed, 18 Dec 2013 00:48:45 GMT
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