jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@adobe.com>
Subject Re: Oak JCR Observation scalability aspects and concerns
Date Fri, 25 Oct 2013 06:53:25 GMT
hi carsten

IMO that should be feasible as the oak editor/commithook interfaces
(and the diff they may make use of) will provide you with the
required information (e.g. childNodeChanged takes both the nodestate
before and after the modification as params).

the biggest challenge i see in terms of backwards compatibility is
that the diff-mechanism in OAK doesn't allow a 1:1 translation
to JCR events as they used to be generated in jackrabbit-core.

however, since we have to be as backwards compatible as possible
under the given circumstances, the sling way of gathering that event
information would IMO the same or very similar as we will use to
generate the JCR events...

we had some discussions during this week's oakathon on how
to get there and how big the impact of changes in that area might
be; in particular but not exclusively when it comes to NODE_MOVED
events (see also OAK-783 [0]). michael consequently updated the
"Differences to Jackrabbit 2" documentation at [1]. in case of
doubt how a given change may impact Sling (or any other application
using JCR events) please drop a line on the list.

IMO it's crucial that we find out if the impact of these changes
is acceptable and what the consequences are in terms of backwards
compatibility and migration effort... we keep getting mixed signals
("be fully compatible" vs "just make it scalable and fast") and need
get a more reliable feedback to in order to be able to calculate
the risk of these changes and take the right decisions for the
next couple of months.

kind regards

[0] https://issues.apache.org/jira/browse/OAK-783
[1] http://jackrabbit.apache.org/oak/docs/differences.html

On 10/25/13 8:03 AM, "Carsten Ziegeler" <cziegeler@apache.org> wrote:

>Rethinking this, I think it's clear that the current way the jcr listener
>works in Sling is not optimal as it reads each and every changed node. So
>think it really would be great if we could directly get the information
>from Oak without the need to additionally process.
>The listener currently:
>1. Compacts observation events into node added, node changed, and node
>removed events - it also collects added/changed/removed properties from
>2. For every added and changed node, it reads the node and the primary
>type, the sling:resourceType and sling:resourceSuperType property
>3. There is a special case, if a node has been added/changed with the name
>"jcr:content" and the parent node is a file node, then the parent node is
>reported  as changed/added.
>I've no idea how the current diff mechanism works in Oak, but I would
>assume that the information for 1. are similar to the result of the diff.
>would hope that the properties for 2. are there as well as they need to be
>diffed against the old value. 3. is more tricky and specific, and I think
>it would be ok if we would do this in Sling as the ratio of files vs other
>content is pretty low usually.
>If Oak could provide this information, we could leverage that in Sling and
>would remove the additional reads - which clearly is an improvement. This
>would require zero changes in applications based on Sling. If Sling is run
>on Oak, this implementation is used, otherwis the current JCR based on is
>WDYT is there any change to get this done?

View raw message