[
https://issues.apache.org/jira/browse/SLING-4751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14567490#comment-14567490
]
Carsten Ziegeler commented on SLING-4751:
-----------------------------------------
The exactly once use case usually results in a job, but you need to make sure
to just create a single job :) We tried to detect whether two instances create
the same job but that failed and is pretty hard to get right. of course
creating two jobs is better than not creating a job at all.
I agree that we might have an optimized version for the caching use case.
However, for example, the scripting is interested in any jsp change under /libs
and apps. Being it a change, an add or a remove. With languages like sightly
this gets more complicated as you have to check for changes to sightly and the
included scripts. So I'm not sure if there is a lot we can do here.
I'm all for making this more scalable, and I fear the hardest use case is
support of something similar to local/external. But we should have this.
For caches, a lot of caches simply throw away the complete cache and are not
interested in detailed changes, so an event like "something changed in this
tree" is suficient. But other cache, like the mentioned scripting is interested
in more detailed changes.
> 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)
