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
