Jackrabbit in a cluster, some pitfalls

2 06 2007

Although jackrabbit in a cluster does work there are one of 2 issues with the 1.3 code base. There is a small patch that needs to be applied to the CusterNode implementation to make terminate the journal record.

@@ -637,6 +637,7 @@
record = journal.getProducer(PRODUCER_ID).append();
record.writeString(workspace);
write(record, nodeId);
+                      record.writeChar('�');
record.update();
setRevision(record.getRevision());
succeeded = true;
see 
https://issues.apache.org/jira/browse/JCR-915

After that there is a race condition under load that is a larger patch described in
https://issues.apache.org/jira/browse/JCR-929
which will cause the effective node to hang on requests into the JCR. There are also some other things to note, in MySQL clustered environment, you MUST have InnoDB as the default table type otherwise you will get collisions on the revision number. In addition you must have the transaction issolation set to READ-COMMITTED, and not REPEATABLE-READ otherwise you will not see the changes propagate from one of the nodes to the other.

About these ads

Actions

Information

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Connecting to %s




Follow

Get every new post delivered to your Inbox.

Join 103 other followers

%d bloggers like this: