ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten.Pfeif...@gebit.de
Subject Re: OverlappingFileLockException when using artifact-lock-nio
Date Wed, 18 Dec 2013 08:37:49 GMT
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