jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dominique Pfister" <dominique.pfis...@day.com>
Subject Re: JackRabbit clustering : "No log file found containing revision: 1111540"
Date Tue, 24 Apr 2007 08:10:29 GMT
Hi Shaun,

On 4/23/07, Shaun Barriball <sbarriba@yahoo.co.uk> wrote:
> 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

This signifies that the file journal's initial record log (the one
starting at revision 0) is completely missing, which is rather

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

Anticipating your question about blobs: they must be stored in a
shared place, either on a mount available to all cluster nodes or in
the database. The blob's contents is not present in the journal, only
its id and type of modification.

This leaves us with two possibilities:

1) The item exists only locally at one repository node. Therefore,
other cluster nodes
    will get an exception when trying to access it.
2) A cluster node has outdated information about the available blobs,
because it didn't
    get all notifications inside the journal. Therefore, it still sees
some blob, that has
    already been deleted.

> So.....are there any wider implications of using clustering e.g.:
>  * blobs have to be stored internally, not externally

Yes, they have to be stored internally. E.g., when using
SimpleDbPersistenceManager or one of its derivative, you have to set
its "externalBLOBs" parameter value to "false".

General guideline in a clustering environment is the following: all
cluster nodes must use the same, "shareable" PersistenceManager, i.e.
one storing its contents in a place accessible to all nodes, because
the journal contains only the information about what items did change,
but not what the changes look like.

> I'll try to write up our findings and 'reference' architecture when all is
> working for the benefit of the group.

Awesome, I'm sure, that will be very helpful!

Kind regards

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

View raw message