On 2012-02-06 21:01, Ingomar Otter wrote:
Hello,
I am currently building a simple replication between two Jackrabbit instances.
I've started off using (synchronous) Observers/Events but I am facing some
challenges due to
the (intresting?) event order.
E.g. I add a file (using webdav) I see the following events (in that order):
PROPERTY_ADDED,2@4376: /Somefile.png/jcr:content/jcr:data
PROPERTY_ADDED,1@4377: /Somefile.png/jcr:content/jcr:mimeType
PROPERTY_ADDED,7@4378: /Somefile.png/jcr:content/jcr:primaryType
PROPERTY_ADDED,5@4379: /Somefile.png/jcr:content/jcr:lastModified
PROPERTY_ADDED,5@4380: /Somefile.png/jcr:created
NODE_ADDED@4381: /Somefile.png/jcr:content
PROPERTY_ADDED,1@4382: /Somefile.png/jcr:createdBy
PROPERTY_ADDED,7@4383: /Somefile.png/jcr:primaryType
NODE_ADDED@4384 :/Somefile.png
Of course I can not replay the events in that order as some parent nodes may be missing.
I could re-order them but then this would at least require some "unit of work"
demarcation as I operate on stream of events (and thus need to cluster/chunk) the events.
Is there a reason why the events are emitted in 'reverse' order (I would assume
per API the node was created first)?
Is there a way to influence this?
Afaik PERSIST (event bundling) is work-in-progress in unstable, would that be a
candidate as Unit-Of-Work marker?
In the meantime I realized that PERSIST events are not in 2.4.0 (but
probably could be ported), and also that you may not need them; they are
only needed and present in Journaled observation -- are you using that?
Best regards, Julian
