jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cédric Damioli <cedric.dami...@anyware-services.com>
Subject Re: Question about event ordering
Date Tue, 07 Feb 2012 20:04:32 GMT
BTW, does someone know why events are actually in the exact reverse order ?
I know the JCR spec states that events could be unordered, but could I 
rely on the fact that Jackrabbit "reverse order" events ?

Regards,
Cédric

Le 07/02/2012 20:51, Ingomar Otter a écrit :
> Hi Julian! :-)
> In the meantime I did for once study the JCR spec and figured that the EventIterator
passed into onEvent() in itself is just a fine event bundle demarcation.
> I just reversed the events inside and now I'm good to go.
>
>> only needed and present in Journaled observation -- are you using that?
> No.
> But only because I discovered it too late ;-)
>
> Cheers,
>   Ingomar
>
> Am 07.02.2012 um 19:16 schrieb Julian Reschke:
>
>> 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
>>
>

-- 
<http://www.anyware-services.com>
www.anyware-services.com <http://www.anyware-services.com>

<http://www.twitter.com/anywareservices> 
<http://www.facebook.com/AnywareServices> <http://eepurl.com/eyrpk>

Inscrivez-vous à notre newsletter

<http://eepurl.com/eyrpk> 	
*Cédric Damioli*
Directeur technique
cedric.damioli@anyware-services.com 
<mailto:cedric.damioli@anyware-services.com>
Tel : +33(0)5 62 19 19 07
Mob : +33(0)6 87 03 61 63
Fax : +33(0)5 61 75 84 12
Adresse : Innopole 13 - 254 avenue de l'Occitane - B.P 97672 - 31676 
LABEGE CEDEX - France

Ametys: Smart Web CMS
<http://www.ametys.org> www.ametys.org <http://www.ametys.org>

Ce message et toutes les pièces jointes (le "Message") sont 
confidentiels et établis à l'intention exclusive de ses destinataires.
Toute modification, édition, utilisation ou diffusion non autorisée est 
interdite.
Anyware Services décline toute responsabilité au titre de ce Message 
s'il a été altéré, déformé, falsifié ou édité, diffusé sans autorisation.

Mime
View raw message