Hi again,
Felix Meschberger wrote:
Inside Sling, we have additional Eventing Support which takes clustering
into account and which may help in ensuring, that only one node is
actually handling certain JCR events. This support implemented in the
extensions/event bundle replicates JCR events as OSGi events and is able
to ensure such translated events are only handled on a single node.
By "Inside Sling", do you mean internally - or something that can be
used by other bundles? If the latter is the case it sounds promising.
But how does this functionality tell if the JCR events are local or not?
Or does "certain JCR events" mean events triggered by Sling code - so
you can put extra information in it / on the node that triggers it?
Yes, I mean, Sling provides this functionality to bundles to use it. How
it works exactly, I don't really know. But there should be a fairly good
descrition at [1].
This did seem like a good solution, but I can't get it working properly.
Tried to follow the documentation. Made a JCR listener that generates an
OSGi event with the topic org/apache/sling/event/job, with custom
event.job.topic and event.job.id. This OGSi event is sent to the
EventAdmin. A custom event handler picks up the event sent back from
Sling's JobEventHandler and should process it.
Since the JCR event is sent to all nodes, and the eventlistener has no
way of knowing if the request is local or external both nodes tries to
make the OSGi event. Sling eventing system will try to make up for this
to allow only one processing of a job by writing jobs to the repository
(/var/eventing/jobs), trying to lock and send back to only one instance
of the application based on if a corresponding job was already there and
a lock was possible or not.
We have sling/jackrabbit on every node and have set up clustering in
jackrabbit with a SimpleDbPersistenceManager to the same MySql database
and journal. In this setup the eventing system works approximatly 4 out
of 5 times when sync delay is set to 5 in the jackrabbit cluster. 1 out
of 5 times both nodes will pass the request through the queue to our
custom handler. It seems the problem is less frequent with a lower sync
delay. Is this system intended for clustered sling with one Jackrabbit
instance (through RMI)?
[1] http://incubator.apache.org/sling/site/eventing-and-jobs.html
Regards,
Erik Buene
