On 2/20/07, Patrick Haggood <[EMAIL PROTECTED]> 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
