jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <...@douma.nu>
Subject Re: Observation
Date Tue, 19 Nov 2013 14:47:25 GMT
On 11/11/2013 07:29 PM, Jukka Zitting wrote:
> Hi,
> On Mon, Nov 11, 2013 at 6:10 AM, Michael Dürig <mduerig@apache.org> wrote:
>> On 8.11.13 10:37 , Alexander Klimetschek wrote:
>>> Regarding journaled observation: retrieving a journal with
>>> ObservationManager#getEventJournal can allow access to events that
>>> happend earlier, right?
>> The spec. doesn't say much here. I'd interpret it as getEventJournal()
>> returns the journal from the point where that call was made rather then from
>> the beginning of times.
> This interpretation makes the event journal essentially useless, as
> one could achieve the same functionality with a normal observation
> listener.
> The point of journaled observation is to be able to access past
> events, which the spec confirms (section 12.6):
>      "Journaled observation allows an application to periodically connect
>      to the repository and receive a report of changes that have occurred
>      since some specified point in the past (for example, since the last
>      connection)."
> Of course section 12.6.2 contradicts that by essentially giving the
> repository free reign to decide which (if any) events to include in
> the journal.
Far more problematic (broken really) is the fact that the spec. uses Dates to 
access/order (skipTo) the events. Which is unreliable and useless in a clustered 
environment. Meaning: unreliable for any serious use-case.

Luckily, Jackrabbit internally maintains a properly ordered and cluster-wide 
journal item revision, as needed anyway for its cluster synchronization.

At Hippo we expose and use this feature through an extended RevisionEventJournal 
[1] adding a skipToRevision(long) method and an RevisionEvent [2] exposing the 
current event its revision.
Implementing this on top of Jackrabbit was really trivial [3] and enables us to 
reliably and asynchronously process past events, in proper order, for things 
like cross-cluster synchronization/replication, etc.

I'm not following the current state of things at Oak enough to know if it also 
will provide some kind of guaranteed orderable and cluster-wide transaction 
revision/timestamp/whatever. But it definitely would be worthwhile (and 
important to us) to be available. Through a fixed/extended EventJournal 
interface like we implemented on top of Jackrabbit or something else doesn't 
really matter, but the functionality IMO is important enough to take into 
consideration for Oak.

Regards, Ate


> So instead of the spec, I think we should look at existing client code
> to determine what kind of expectations they have.
> BR,
> Jukka Zitting

View raw message