Hi Michael,
the stack trace indicate that jackrabbit is not properly shutdown. when
jackrabbit is started up again the query handler runs recovery code as can be
seen in the stack trace:
Michael Neale wrote:
at org.apache.jackrabbit.core.query.lucene.Recovery.run(Recovery.java
:160)
at org.apache.jackrabbit.core.query.lucene.Recovery.run(Recovery.java
:85)
at org.apache.jackrabbit.core.query.lucene.MultiIndex.<init>(
MultiIndex.java:268)
the following IllegalArgumentException is probably a bug. I'll create a jira
issue and fix it.
java.lang.IllegalArgumentException: already contains: _c
at org.apache.jackrabbit.core.query.lucene.IndexInfos.addName(
IndexInfos.java:170)
at org.apache.jackrabbit.core.query.lucene.MultiIndex.deleteIndex(
MultiIndex.java:716)
at
org.apache.jackrabbit.core.query.lucene.MultiIndex$DeleteIndex.execute(
MultiIndex.java:1553)
at org.apache.jackrabbit.core.query.lucene.MultiIndex.executeAndLog(
MultiIndex.java:809)
at org.apache.jackrabbit.core.query.lucene.MultiIndex.flush(
MultiIndex.java:740)
at org.apache.jackrabbit.core.query.lucene.Recovery.run(Recovery.java
:160)
[...]
when trying to login to the repository the next time. This is extremely
alarming to me. If I go in and blow away the contents of the index
directories, it will then work for a while after that (once it has
recreted)
but it only takes a dozen or so "cycles" (startup, run a query,
shutdown) to
get back into this state.
Can you please make sure that Jackrabbit is shutdown properly in your cycles and
check if you still see those exceptions? I could imagine that there's an issue
in the index recovery code that only comes into play when one repeatedly kills a
jackrabbit instance and then starts it again.
This got me thinking, how are the lucene indexes kept in sync - they can't
be part of the transaction can they? I mean they can try to be. This
worries
me, I don't like being worried.
the lucene indexes are updated after a jackrabbit transaction is committed. if
the jvm process is killed during that update, the index may be ouf of sync. See:
http://issues.apache.org/jira/browse/JCR-204
this is a consequence of the decoupled design of the persistence manager and the
query handler. one solution would be to have a two-phase commit for both changes
to the persistence manager and the query handler. but this would require a more
sophisticated interface for the persistence manager.
Any advice much appreciated, this is pretty much stopping the show for me
now.
The more details I see from your issue, the more I think it is caused by your
test setup. Please make sure that you do a clean shutdown in your test cycle.
regards
marcel
