You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Carsten Ziegeler (JIRA)" <ji...@apache.org> on 2014/03/25 08:27:45 UTC
[jira] [Resolved] (SLING-3279) Leverage improved observation
support from Oak
[ https://issues.apache.org/jira/browse/SLING-3279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Carsten Ziegeler resolved SLING-3279.
-------------------------------------
Resolution: Fixed
I've committed the latest version of the patch and also switched to using the EventProperties class when creating the OSGi event as this avoids copying the event payload
> 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
> Fix For: JCR Resource 2.3.8
>
> Attachments: SLING-3279-combined-2.patch, SLING-3279-combined-3.patch, SLING-3279-combined-4.patch, SLING-3279-combined-5.patch, SLING-3279-combined-6.patch, SLING-3279-combined-7.patch, 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)