[
https://issues.apache.org/jira/browse/SLING-4751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14943203#comment-14943203
]
Stefan Egli commented on SLING-4751:
------------------------------------
bq. Do you have any suggestions what can be done to increase the performance?
Not very concrete ones yet. Perhaps some fiddling with EventHandler properties.
The internal vs external part could perhaps be modelled via some
{{EventConstants.EVENT_FILTER}}? Or by introducing
{{SlingConstants.TOPIC_RESOURCE_EXTERNAL_*}} ..
In any case, the goal should be to limit the number of paths for which external
events should be delivered by the repository (eg Oak). If the external events
are filtered further up the stack, ie after Oak has delivered them to the
{{OsgiObservationBridge}}, then I think it's too late: the work has already
been done. Best would be if {{OsgiObservationBridge}} could come up with a
limited lists of paths for it wants external events to be delivered. Perhaps
that is feasible with some peeking into EventAdmin?
> New Observation Support
> -----------------------
>
> Key: SLING-4751
> URL: https://issues.apache.org/jira/browse/SLING-4751
> Project: Sling
> Issue Type: Improvement
> Components: API, JCR, ResourceResolver
> Reporter: Carsten Ziegeler
> Assignee: Tomek Rękawek
> Fix For: API 2.10.0, Resource Resolver 1.2.8
>
>
> Mail thread:
> http://mail-archives.apache.org/mod_mbox/sling-dev/201505.mbox/%3C555983F2.20402%40apache.org%3E
> Starting mail
> Right now, resources changes are propagated through event admin - which
> at the time sounded like a good idea. Over time, this has shown to be a
> bottle neck.
> Basically there are at least three problems:
> - the sender of the resource events does not know whether there is a
> receiver, therefore events for each and every change need to be sent
> - event objects are immutable and therefore all relevant data needs to
> be calculated upfront, even if it's not used. For example a resource
> event contains the resource type which needs to be fetched from the
> repository, even if no one is interested in it.
> - receivers of the events can't easily act on behalf of the user who
> initiated the change.
> I created a new listener api at [1] which defines a ResourceListener
> interface and some ways how to specify the events one is interested in.
> The user aware resource listener allows to act on behalf of the user (if
> that information is available).
> On the other side, a new service, the ObservationReporter [2] is
> defined. Resource providers report changes through this interface. The
> payload of such an event is an interface which allows for lazy retrieval
> of the information.
> We can also use this mechanism for compatibility and an implementation
> of the observation reporter might sent all events via the event admin.
> [1]
> https://svn.apache.org/repos/asf/sling/whiteboard/cziegeler/api-v3/src/main/java/org/apache/sling/api/resource/observation/
> [2]
> https://svn.apache.org/repos/asf/sling/whiteboard/cziegeler
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
