[
https://issues.apache.org/jira/browse/SLING-3279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13923891#comment-13923891
]
Michael Dürig commented on SLING-3279:
--------------------------------------
[~cziegeler] this is basically a rewrite of JcrResourceListener and the
respective unit test for Oak, not an improvement of the existing code. I
decided to base this on the existing bundle as this was the easiest way for me
to get this done quickly. As I understood our discussion from last week, you
agreed to figure out how to best incorporate this into Sling. My suggestion
would be as a bundle on its own, which could be used as an alternative to the
existing one when running on Oak. But since my overall view of Sling is
limited, you might come up with a much better alternative.
If you prefer I could also attach a zip with the code or point you to a fork on
Github.
> Leverage improved observation support from Oak
> ----------------------------------------------
>
> Key: SLING-3279
> URL: https://issues.apache.org/jira/browse/SLING-3279
> Project: Sling
> Issue Type: Improvement
> Components: JCR
> Reporter: Michael Dürig
> Assignee: Carsten Ziegeler
> Attachments: SLING-3279.patch
>
>
> OAK-1120 introduces better support for observation, which could be used by
> Sling. For example JcrResourceListener could be rewritten leveraging Oak's
> Observer. Since Oak observers already run on background threads further
> decoupling (like it is currently done) is not necessary. This makes it
> unnecessary to queue potentially a lot of events in Sling. Since neither Oak
> there does queue events (they are generated by need) this will probably
> greatly improve scalability in the face of many events.
> Furthermore OSGi filters could be passed down and translated to Oak such that
> filtering is done much closer to the source of the events.
> Finally instead of using a centralised event dispatcher (like
> JcrResourceListener currently is) it would be better to install a dedicated
> Observer for each OSGi event listener since dispatching is already handled by
> Oak and thread pooling (i.e. assigning threads for dispatching call backs to
> observers) can be controlled through Sling's thread pool support (*). This
> has the further advantage of making individual stats available for the
> listeners through JMX.
> (*) Register an OakExecutor backed by e.g. a Sling thread pool and it will be
> picked up by Oak.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
