Hi Shaun,
On 4/23/07, Shaun Barriball <[EMAIL PROTECTED]> 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
strange.
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
Dominique
-----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
