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

Reply via email to