Carsten Ziegeler commented on SLING-6070:

No, the maps can't be removed entirely. For example, you get an addNode event 
followed by N addProperty events. We clearly don't want to send out the change 
events as the add is enough. Similar is with removal.
I'm not against reducing memory consumption but relying on some particular 
order seams to be very fragile to me. If the order changes, and that might 
happen, Sling is broken.
Sending out each event as a single event is not ideal either, thats why 
reportChanges has a list argument. So we can send a set of changes in one go, 
reducing overhead.
I agree, that large commits could happen in batches in some way, but atm I fail 
to see how this can be done reliable and is independent of potential changes in 
the underlying JCR implementation

> 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