jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <cziege...@apache.org>
Subject Re: Oak JCR Observation scalability aspects and concerns
Date Fri, 25 Oct 2013 06:03:22 GMT
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 I
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 the
2. For every added and changed node, it reads the node and the primary node
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. I
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?


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message