[
https://issues.apache.org/jira/browse/SLING-3279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13846158#comment-13846158
]
Bertrand Delacretaz commented on SLING-3279:
--------------------------------------------
There isn't more to my f2f conversation with Michael than what I mentioned
above, he just showed me how the new Oak observation stuff works. My notes
above are just rough ideas, everything's still open in terms of implementation
as far as I'm concerned.
I think we are actually discussing two distinct things:
a) Ideally, JcrResourceListener should not listen to more JCR/Oak events than
it actually needs to supply the OSGi EventHandlers that are listening to its
OSGi events. This is where we might analyze the set of event.topics and/or
event.filter service properties of registered EventHandlers, to find out which
OSGi events must be sent. We can then derive an optimized JCR/Oak observation
setup from that.
b) Optimize how threads are used to deliver JCR/Oak events, this is a separate
concern and might be totally independent of a)
> 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
>
> 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.1.4#6159)
