Hi Dominique,
Thanks for the quick and complete reply.
1) I tried to simply delete the revision file which caused another exception
on startup:
Caused by: java.io.IOException: No log file found containing revision: 0
at
org.apache.jackrabbit.core.cluster.FileRecordCursor.getRecordLog(FileRecordC
ursor.java:121)
at
org.apache.jackrabbit.core.cluster.FileRecordCursor.next(FileRecordCursor.ja
va:98)
at
org.apache.jackrabbit.core.cluster.FileJournal.sync(FileJournal.java:303)
... 51 more
org.apache.jackrabbit.core.cluster.JournalException: Unable to iterate over
modified records: No log file found containing revision: 0
2) Copying the revision file from another node to the broken node DID allow
the node to restart. However when accessing content, in particular blobs
we're getting lots of:
ERROR failed to fetch item
5e828f6d-3fbb-451d-95ca-84133c33590d/{http://www.jcp.org/jcr/1.0}data,
skipping...
javax.jcr.RepositoryException: failed to retrieve item state of item
5e828f6d-3fbb-451d-95ca-84133c33590d/{http://www.jcp.org/jcr/1.0}data:
failed to read property state:
So.....are there any wider implications of using clustering e.g.:
* blobs have to be stored internally, not externally?
* etc?
I'll try to write up our findings and 'reference' architecture when all is
working for the benefit of the group.
Regards,
Shaun.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Dominique Pfister
Sent: 23 April 2007 11:18
To: [email protected]
Subject: Re: JackRabbit clustering : "No log file found containing revision:
1111540"
Hi Shaun,
Please note, that there was a considerable refactoring done on clustering.
This new, hopefully more stable version will be available in Jackrabbit 1.3.
> So I'd appreciate any feedback from those in the know on:
>
> * how can the above issue be resolved?
Apparently, the cluster node in question has a bad revision id stored.
You may either:
- Stop the node, delete its revision file, named "revision", located in the
repository
directory, and restart the node. The node will then re-iterate from the
beginning of
the revision log and integrate all changes.
- If this doesn't help and the error still occurs, you may copy another
node's revision file
to this node. Again, stop the node before doing such a change and restart
it afterwards.
It will then no longer complain about missing revisions
> * is it more reliable to use the Database Journal (with which we've
> also had issues)?
When using file-based journaling on a mounted network share, there might be
delays, where revisions appear before the actual revision id has been
updated. In such a scenario, I'd prefer using the DatabaseJournal. Moreover,
DatabaseJournal's revision ids are simply counter-based record ids, whereas
FileJournal's revision ids actually represent absolute file positions, which
makes errors harder to track.
Kind regards
Dominique
