Hi, Am Donnerstag, den 29.05.2008, 15:43 +0200 schrieb Erik Buene: > Hi Felix, > > Felix Meschberger wrote: > > Hi Erik, > > > > Just a quick note, as Alex actually pretty completely responded. > > > > >From your description, I assume, this is mostly a Jackrabbit/JCR issue. > > So you might be better off asking on the jackrabbit dev (or user list), > > where also the people implementing clustering are hanging around. > > > This was my initial thought, but it's not really a Jackrabbit issue, > since a pure Jackrabbit instance would have no problem doing this cast - > the problem is introduced in sling when using OSGi bundles. So maybe > more of a OSGi/Felix issue then?..
Well, yes and no. The problem is a Jackrabbit one, as you are faced with the situation to handle an Observation Event on a single node, despite it being distributed to all nodes. Your use of the internal EventImpl class is problematic regardless of whether you run directly with Jackrabbit or in Sling. > > 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]. > > But, as Alexander said, using the implementation class directly is not a > > good idea: First it is not future-proof in terms of changes to the > > Jackrabbit implementation. And secondly - much more important in terms > > of OSGi - it locks you into a single use case and bundles. > > > > > I see that, so another solution would be preferable as long as we > reliably can get only one node to process the event without introducing > a single point of failure. Regards Felix [1] http://incubator.apache.org/sling/site/eventing-and-jobs.html
