You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Stefan Egli (JIRA)" <ji...@apache.org> on 2016/09/27 12:37:20 UTC
[jira] [Commented] (SLING-6070) Reduce temporary storage required
in JcrResourceListener, call reportChanges earlier
[ https://issues.apache.org/jira/browse/SLING-6070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15525986#comment-15525986 ]
Stefan Egli commented on SLING-6070:
------------------------------------
Open question here is: are we allowed to make this assumption that the events are ordered in a breadth-first manner? Or should we rather rewrite the OakResourceListener (or come up with a OakResourceListener2) that uses a Jcr EventListener and does this assumption? Perhaps doing it in the (theoretically) generic JcrResourceListener would be too tightly coupled with Oak
> Reduce temporary storage required in JcrResourceListener, call reportChanges earlier
> ------------------------------------------------------------------------------------
>
> Key: SLING-6070
> URL: https://issues.apache.org/jira/browse/SLING-6070
> Project: Sling
> Issue Type: Improvement
> Components: JCR
> Affects Versions: JCR Resource 2.8.0
> Reporter: Stefan Egli
> Fix For: JCR Resource 2.8.2
>
>
> As noticed in OAK-4581 ([here|https://issues.apache.org/jira/browse/OAK-4581?focusedCommentId=15525601&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15525601]) one advantage of using OakResourceListener over JcrResourceListener (hence the term 'optimize for oak' of the config parameter) is that OakResourceListener uses a NodeObserver, which calls added/removed/changed after each child traversal has finished. This will in turn be used by the OakResourceListener to call ObservationReporter.reportChanges. In the JcrResourceListener.onEvent case however this is not possible, as the events are delivered for each node/property individually, and they first have to be 'mapped' to ResourceChanges. This is currently done by keeping maps of added/removed/changed ResourceChanges and only after all events (that are passed in 1 onEvent) are processed is reportChanges invoked. This has the downside of a potentially very large temporary memory usage (these maps can get big).
> A suggested improvement is to follow the same pattern as is done in the OakResourceListener/NodeObserver pair: to forward the events (by callling reportChanges) as early as possible. Since Oak uses a breadth-first tree traversal when compiling the jcr events, this fact can be used to detect the earliest possible moment to forward events, which is as soon as a child traversal has finished. That way, only parent changes need to be kept, not the entire tree of changes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)