[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=15582014#comment-15582014 ] Stefan Egli commented on SLING-6070: Agreed, we shouldn't make any dependency on underlying order. So if we can't do without the maps then let's see if this is really a problem. Perhaps it's not as extremely large commits aren't much of a reality. > 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=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)
[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=15581902#comment-15581902 ] 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=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)
[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=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=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)
[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=15579730#comment-15579730 ] Carsten Ziegeler commented on SLING-6070: - I've optimized the memory handling a little bit, reduced unnecessary object creation, but still the whole set is built before it is send out. The properties support is deprecated and removed from the listener. I think that's all we can do for now [~egli] WDYT? > 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=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)
[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=15565377#comment-15565377 ] Stefan Egli commented on SLING-6070: bq. 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. Unlike written in the comment, Sling should not make this assumption. So this statement is actually wrong/useless > 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=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)
[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=15549579#comment-15549579 ] Carsten Ziegeler commented on SLING-6070: - Yes I think that makes sense > 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=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)
[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=15549108#comment-15549108 ] Stefan Egli commented on SLING-6070: should we even mark it as deprecated then? > 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=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)
[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=15549079#comment-15549079 ] Carsten Ziegeler commented on SLING-6070: - Yes, I think we don't need to support this for the ResourceChangeListeners - these things are clearly marked optional and looking at this now I think we should have never added it to the ResourceChange class. > 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=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)
[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=15549068#comment-15549068 ] Stefan Egli commented on SLING-6070: [~cziegeler], re my question on OAK-4581: bq. If we no longer propagate property changes in the JRL, then we could avoid these maps. Do I understand you correct that you're suggesting to remove this support then? This would allow us indeed to get rid of the OakResourceListener. wdyt? > 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=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)
[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=15532197#comment-15532197 ] Stefan Egli commented on SLING-6070: See [sub-discussion|https://issues.apache.org/jira/browse/OAK-4581?focusedCommentId=15522741=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15522741] in length ticket OAK-4581 which suggests to get rid of the OakResourceListener but pointed at reasons for its introduction, which included the high memory consumption which SLING-6070 is trying to get rid of. > 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=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)
[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=15526129#comment-15526129 ] Stefan Egli commented on SLING-6070: Depending on the outcome of OAK-4853 this might become obsolete > 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=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)
[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=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=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)
