jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Guggisberg" <stefan.guggisb...@gmail.com>
Subject Re: OverlappingFileLockException using DerbyPersistenceManager
Date Wed, 21 Feb 2007 14:34:44 GMT
On 2/20/07, Patrick Haggood <codezilla@email.com> wrote:
> On Mon, 2007-02-19 at 17:28 +0100, Stefan Guggisberg wrote:
> > ok, i guess we can rule derby out.
> >
> > it seems like the same process/jvm tries to acquire a file lock
> > on the repository .lock file.
> >
> > you should see a related warning in your jackrabbit log file.
> >
>
> Haven't tried your recommendation, but i got a jackrabbit log (finally -
> log4j.properties + Netbeans = nightmare):
>
> What's interesting is the "existing lock" message:
> 18:32:07,627 [main] WARN core.RepositoryImpl             - Existing lock
> file
> at /home/pbh/projects/lab/javadev/nbprojects/UnityJSR170/repository/.lock deteteced.
Repository was not shut down properly.
>
> Before each test, I delete the repository directory and the log.  I do
> not understand how it's finding this existing lock each time.

very strange indeed. the only plausible explanation for the above warning
would be that there are more than 1 running instances using the same
configuration... the subsequent OverlappingFileLockException further seems
to confirm this.

btw, afaik OverlappingFileLockException is only thrown on linux,
FileChannel#getLock on windows e.g. returns null in the same situation.

you might want to test on a different platform to further isolate the issue.
you could also place a breakpoint at the top of the
RepositoryImpl#acquireRepositoryLock
method, step through the code, verify the contents of your fs etc.

personally i haven't come across a similar issue.

cheers
stefan

Mime
View raw message