jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shaun Barriball" <sbarr...@yahoo.co.uk>
Subject RE: JackRabbit clustering : "No log file found containing revision: 1111540"
Date Mon, 23 Apr 2007 16:37:38 GMT
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
        ... 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
javax.jcr.RepositoryException: failed to retrieve item state of item
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.

-----Original Message-----
From: dominique.pfister@gmail.com [mailto:dominique.pfister@gmail.com] On
Behalf Of Dominique Pfister
Sent: 23 April 2007 11:18
To: users@jackrabbit.apache.org
Subject: Re: JackRabbit clustering : "No log file found containing revision:

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
  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

View raw message