[
https://issues.apache.org/jira/browse/SLING-3279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13845841#comment-13845841
]
Carsten Ziegeler commented on SLING-3279:
-----------------------------------------
I totally agree with Felix - and as he points out - if events are send
synchronously *and* blacklisting is disabled for those listeners, no additional
threads are used.
If there are plans/ideas for taking over event admin functionality, we really
should a) avoid this and b) discuss it here - so more nodes about the private
f2f would really help. Thanks
Apart from that, I'm all for improving the jcr resource listener for Oak and
leveraging whatever is there - however, we need to make sure that the jcr
resource bundle works in both situations: any jcr repository and Oak
implementation, so it's really compatible
> 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)
