Erik Buene wrote:
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.
This sounds good - now, the optimum would be if you can start with an
OSGi event instead of relying on changes in the repository. But I guess
this is not working in your scenario.
The event/job mechanism is exactly designed for these cases. The
important part when creating the job.id is that it is unique in the
sense that two different changes get a different job id *and* it has to
be the same on all cluster nodes. Only then the job mechanism is able to
detect that the same job has been started on different nodes.
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.
Yes, that's based on the job.id.
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)?
Yes, it is intended for all clustering scenarios :)
What dou you mean by "both nodes will pass the request through the queue
to our custom handler"?
Carsten
--
Carsten Ziegeler
[EMAIL PROTECTED]
