[
https://issues.apache.org/jira/browse/SLING-3279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13931832#comment-13931832
]
Michael Dürig commented on SLING-3279:
--------------------------------------
bq. is there any chance we can get away with the extra reads done in the
sendOsgiEvent() method?
If you are referring to the {{nt:file}} normalisation and calculation of
resource (super) type, then yes we can probably push this into Oak. I left this
out from the initial patch because I don't know the exact algorithm for
determining those. If you can sketch the algorithm out for me (e.g. given a Jcr
Node instance) I'll try to port that to
{{org.apache.jackrabbit.oak.plugins.observation.NodeObserver}}.
> 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-combined.patch, 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)
