[
https://issues.apache.org/jira/browse/SLING-6070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15581779#comment-15581779
]
Stefan Egli commented on SLING-6070:
------------------------------------
My original idea for this improvement was to call {{reportChanges}} for each
{{nextEvent()}} call. The reason for going that route would be that in theory
one {{onEvent}} call can reflect a very large commit - and during that commit
at the moment these addedEvents/changedEvents/removedEvents methods are all
piling up (in memory..), and afaik this originally was also one of the reasons
why OakResourceListener was used. With the properties support being removed I
think it should now be possible to 'forward' nextEvent directly to
reportChanges - thus these maps could be removed entirely.
> 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
> Assignee: Carsten Ziegeler
> Fix For: JCR Resource 2.9.0
>
>
> 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)