[
https://issues.apache.org/jira/browse/SLING-4751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14572759#comment-14572759
]
Stefan Egli edited comment on SLING-4751 at 6/4/15 1:39 PM:
So for the former cache cases you could add an 'AggregateResourceListener'
which is only interested in changes at-or-under a certain path, but not all the
details of what exactly has changed under that path. That would allow to
optimize further down the stack in oak even - if you propagate this information
accordingly.
I think the advantage of having specialized ResourceListeners instead of just a
generic one is that it makes the use cases much more explicit, thus making
users also more aware of what implications they can have on
scalability/performance when using the wrong listener. The generic one could
even not be supported at all in a cluster for example.
Additionally it would allow us to look at each listener class and optimize each
case individually for scalability. With the goal that as few external changes
as possible would have to be processed in a cluster. It would also allow to
have monitoring etc on the different types perhaps even showing their influence
they have on scalability/performance.
All of these optimizations would become difficult to introduce with just having
one generic type IMO. Which, if not optimized, will eventually become a
scalability bottleneck.
was (Author: egli):
So for the former cache cases you could add an 'AggregateResourceListener'
which is only interested in changes at-or-under a certain path, but not all the
details of what exactly has changed under that path. That would allow to
optimize further down the stack in oak even - if you propagate this information
accordingly.
I think the advantage of having specialized ResourceListeners instead of just a
generic one is that it makes the use cases much more explicit, thus making
users also more aware of what implications they can on scalability/performance
have when using the wrong listener. The generic one could even not be supported
at all in a cluster for example.
Additionally it would allow us to look at each listener class and optimize each
case individually for scalability. With the goal that as few external changes
as possible would have to be processed in a cluster. It would also allow to
have monitoring etc on the different types perhaps even showing their influence
they have on scalability/performance.
All of these optimizations would become difficult to introduce with just having
one generic type IMO. With, if not optimized, will eventually become a
scalability bottleneck.
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: Carsten Ziegeler
Fix For: API 2.10.0, Resource Resolver 1.2.6
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)
