"Directory was previously created with a different LockFactory" when open, close, delete a repository in a loop

• Key: JCR-1879
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Minor
• Assignee: Unassigned
• Reporter: Thomas Mueller
• Component/s: jackrabbit-core
• Affects Version/s: 1.6.0
• Fix Version/s: 1.6.0

Description

Opening a TransientRepository in a loop throws the exception "Directory was previously created with a different LockFactory instance".

Test case:

for (int i = 0; i < 3; i++) {
FileUtils.deleteDirectory(new File("repository"));
Repository rep = new TransientRepository();
Session session = rep.login(new SimpleCredentials("", new char[0]));
session.logout();
}

The problem seems to be that org.apache.lucene.store.FSDirectory.DIRECTORIES is not cleared (FSDirectory.close() is not called?).

Stack trace:

Exception in thread "main" javax.jcr.RepositoryException: Directory was previously created with a different LockFactory instance; please pass null as the lockFactory instance and use setLockFactory to change it: Directory was previously created with a different LockFactory instance; please pass null as the lockFactory instance and use setLockFactory to change it: Directory was previously created with a different LockFactory instance; please pass null as the lockFactory instance and use setLockFactory to change it
at org.apache.jackrabbit.core.SearchManager.initializeQueryHandler(SearchManager.java:555)
at org.apache.jackrabbit.core.SearchManager.<init>(SearchManager.java:239)
at org.apache.jackrabbit.core.RepositoryImpl.getSystemSearchManager(RepositoryImpl.java:688)
at org.apache.jackrabbit.core.RepositoryImpl.access$3(RepositoryImpl.java:681)
at org.apache.jackrabbit.core.RepositoryImpl$WorkspaceInfo.getSearchManager(RepositoryImpl.java:1780)
at org.apache.jackrabbit.core.RepositoryImpl.initWorkspace(RepositoryImpl.java:667)
at org.apache.jackrabbit.core.RepositoryImpl.initStartupWorkspaces(RepositoryImpl.java:480)
at org.apache.jackrabbit.core.RepositoryImpl.<init>(RepositoryImpl.java:321)
at org.apache.jackrabbit.core.RepositoryImpl.create(RepositoryImpl.java:618)
at org.apache.jackrabbit.core.TransientRepository$2.getRepository(TransientRepository.java:241)
at org.apache.jackrabbit.core.TransientRepository.startRepository(TransientRepository.java:261)
Caused by: java.io.IOException: Directory was previously created with a different LockFactory instance; please pass null as the lockFactory instance and use setLockFactory to change it
at org.apache.lucene.store.FSDirectory.getDirectory(FSDirectory.java:192)
at org.apache.jackrabbit.core.query.lucene.directory.FSDirectoryManager.getDirectory(FSDirectoryManager.java:64)
at org.apache.jackrabbit.core.query.lucene.MultiIndex.<init>(MultiIndex.java:227)
at org.apache.jackrabbit.core.query.lucene.SearchIndex.doInit(SearchIndex.java:477)
at org.apache.jackrabbit.core.query.AbstractQueryHandler.init(AbstractQueryHandler.java:59)

Comments

[Marcel Reutegger]

Fixed in svn revision: 720540

[Jukka Zitting]

Merged to the 1.5 branch in revision 731989.

[Jukka Zitting]

Oops, it seems like this issue only affected post-1.5 code, so in revision 732121 I reverted my previous merge.

[Sébastien Launay]

I have the same exception using Jackrabbit 1.5.3 and Lucene 2.3.2:
java.io.IOException: Directory was previously created with a different LockFactory instance; please pass null as the lockFactory instance and use setLockFactory to change it
at org.apache.lucene.store.FSDirectory.getDirectory(FSDirectory.java:192)
at org.apache.jackrabbit.core.query.lucene.PersistentIndex.<init>(PersistentIndex.java:63)
at org.apache.jackrabbit.core.query.lucene.MultiIndex.getOrCreateIndex(MultiIndex.java:587)
at org.apache.jackrabbit.core.query.lucene.MultiIndex$CreateIndex.execute(MultiIndex.java:1675)
at org.apache.jackrabbit.core.query.lucene.MultiIndex.executeAndLog(MultiIndex.java:972)
at org.apache.jackrabbit.core.query.lucene.MultiIndex.commitVolatileIndex(MultiIndex.java:1017)
at org.apache.jackrabbit.core.query.lucene.MultiIndex.flush(MultiIndex.java:862)
at org.apache.jackrabbit.core.query.lucene.Recovery.run(Recovery.java:172)
at org.apache.jackrabbit.core.query.lucene.Recovery.run(Recovery.java:85)
at org.apache.jackrabbit.core.query.lucene.MultiIndex.<init>(MultiIndex.java:311)
at org.apache.jackrabbit.core.query.lucene.SearchIndex.doInit(SearchIndex.java:456)
at org.apache.jackrabbit.core.query.AbstractQueryHandler.init(AbstractQueryHandler.java:59)
at org.apache.jackrabbit.core.SearchManager.initializeQueryHandler(SearchManager.java:553)
at org.apache.jackrabbit.core.SearchManager.<init>(SearchManager.java:239)
at org.apache.jackrabbit.core.RepositoryImpl$WorkspaceInfo.getSearchManager(RepositoryImpl.java:1761)
at org.apache.jackrabbit.core.RepositoryImpl.initWorkspace(RepositoryImpl.java:667)
at org.apache.jackrabbit.core.RepositoryImpl.initStartupWorkspaces(RepositoryImpl.java:480)
at org.apache.jackrabbit.core.RepositoryImpl.<init>(RepositoryImpl.java:321)
at org.apache.jackrabbit.core.RepositoryImpl.create(RepositoryImpl.java:618)
at org.apache.jackrabbit.core.TransientRepository$1.getRepository(TransientRepository.java:187)
at org.apache.jackrabbit.core.TransientRepository.startRepository(TransientRepository.java:261)
at org.apache.jackrabbit.core.TransientRepository.login(TransientRepository.java:329)
at org.apache.jackrabbit.core.TransientRepository.login(TransientRepository.java:359)
at org.ametys.plugins.oswf.store.JackrabbitWorkflowStore._getSession(JackrabbitWorkflowStore.java:142)
at org.ametys.plugins.oswf.store.JackrabbitWorkflowStore.moveToHistory(JackrabbitWorkflowStore.java:778)
at com.opensymphony.workflow.AbstractWorkflow.createNewCurrentStep(AbstractWorkflow.java:1474)
at com.opensymphony.workflow.AbstractWorkflow.transitionWorkflow(AbstractWorkflow.java:1256)
at com.opensymphony.workflow.AbstractWorkflow.doAction(AbstractWorkflow.java:567)
at org.ametys.plugins.oswf.store.AbstractFunctionalWorkflowTest.testExampleWorkflow(AbstractFunctionalWorkflowTest.java:124)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at junit.framework.TestCase.runTest(TestCase.java:168)
at junit.framework.TestCase.runBare(TestCase.java:134)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)
at junit.framework.TestSuite.runTest(TestSuite.java:232)
at junit.framework.TestSuite.run(TestSuite.java:227)
at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:81)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

In my test case, i create lots of workflows and they creates lots of JCR sessions.
If i use a pool of sessions, i can not reproduce this issue.

So, this issue also affect the 1.5 branch and a new merge :) will be greatly appreciated...

[Marcel Reutegger]

> So, this issue also affect the 1.5 branch and a new merge :) will be greatly appreciated...

I'm not able to reproduce this issue on the 1.5 branch. Can you please create a new issue and provide a test? Thanks.

After trying to reproduce the bug in a test case (which i was unable) i found that in my initial test case (stack trace above) two repositories were simultaneously started.
Opening a session in the second repository will fail with a traditional "lock not acquired" exception.
But opening a second session in this repository will acquire the lock but will throw the above exception.

Indeed, the lock is checked when trying to create the first session, then the lock file is deleted (RepositoryImpl.doShutdown() calls repLock.release()) because the session creation fails.
The second session will not find a lock (previously removed) and then will fail with the lock factory instance exception.

So, this is not the same bug and clearly a twisted case ;).
But i can create a new issue in order to avoid lock deletion if this is not the right repository.

[Marcel Reutegger]

> But i can create a new issue in order to avoid lock deletion if this is not the right repository.

please do so, this clearly sounds like a bug.

[Ryan Vanderwerf]

I'm having the same issue in 1.4.2. Is this issue back ported to a 1.5 release?

[Marcel Reutegger]

There is some confusion about issues related to this exception message. *This* issue fixes a bug that was only present in jackrabbit-core trunk and was never released. The issue you're interested in is probably JCR-2057.