jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis van der Laan <d.g.van.der.l...@rug.nl>
Subject Re: Unable to start second node in a cluster
Date Tue, 15 Dec 2009 23:18:59 GMT
Dennis van der Laan wrote:
> Hi,
>
> I have two identical machines (A and B) running Jackrabbit 1.6.0 on
> Tomcat 6.0. I made an empty folder on each machine, containing only a
> repository.xml file, again both identical (using System properties to
> set the cluster ID). The repository configuration uses a bundle PM
> (Oracle 10g database) and a local filesystem for all components.
>
> When I start A, the repository tables are created in the database and
> all works well. After the repository is initialized, I add some custom
> namespaces and nodetypes, and create a basic folder hierarchy.
> Then, when I start B, I get the following exception:
>
> 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)
>
> When I stop both A and B, and starting them again, A can startup again
> but B still gives the exception.
>
> I removed all tables from the database and re-created the repository
> folders on both machines and inverted the startup: first I started B and
> then I started A. Now B starts up fine, but A gives the exception.
>
> In the LOCAL_REVISIONS table I can see both cluster instances add their
> revision (revision 12 for the started repository and 0 for the failed
> repository).
>
> What am I doing wrong here? I found an issue involving LockFactory
> exceptions, but they all had to do with starting and stopping multiple
> repositories in the same VM or concurrently on the same machine.
>   
I changed the repository configuration from using a bundle database PM
to a simple database PM (from
org.apache.jackrabbit.core.persistence.bundle.OraclePersistenceManager
to org.apache.jackrabbit.core.persistence.db.OraclePersistenceManager).
Now it works! But a bundle PM should have better performance. Is this a
bug? Is anybody else using a bundle database PM in a cluster configuration?

Thanks,
Dennis

-- 
Dennis van der Laan


Mime
  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message