[
https://issues.apache.org/jira/browse/SLING-8946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17045315#comment-17045315
]
Dirk Rudolph commented on SLING-8946:
-------------------------------------
Ok got it. In this case the logic in BasicObservationReporter prevents the
registration of an unnecessary listener which depending on the RP costs some
overhead. ResourceChanges reported via the BasicObservationReporter are also
filtered again in a later stage.
I don't see any way to implement this in linear time keeping the behaviour that
when ever a ResourceProvider appears/disappears it immediately is
activated/deactivated. No matter how the control flow goes as long as the root
ResourceProvider has to keep track on excluding all overlapping
ResourceProviders the time complexity is at least n^2.
Giving some background of the issue and why I set it critical:
We have a ResourceProvider registered on a path (/content/foo), overlapping the
root ResourceProvider. This ResourceProvider resolves Resources from other
areas of the repository (for example in /etc) and so "mounts" them on deep
paths below /content/foo. Any other path that cannot be resolved to one of the
"other areas" will be delegated to the parent/root ResourceProvider. For
example:
We have in /etc
/etc/appletrees/en_GB/apple [sling:resourceType='fruit']
And in /content/foo we have
/content/foo/en_GB => from root ResourceProvider
/content/foo/en_GB/fruits => from root ResourceProvider
/content/foo/en_GB/fruits/apple => from custom ResourceProvider found by a
"Resource in /etc with resourceType='fruit' and name='apple'"
Now this works fine as long as it comes to events and ResourceChangeListeners,
as they are used for sling:alias for example. We implemented the event
listeners as instructed by the product's support team (actually registering
listeners on the same JCR repository as the root ResourceProvider does) and
now, depending on the start order of the services and as stated in the
description, we receive ResourceChanges sometimes twice (first time from the
root ResourceProvider and second time from our custom ResourceProvider).
(p.s. I know this setup is not really lean and can probably be implemented
differently)
> Non-deterministic shadowing of resource observation
> ---------------------------------------------------
>
> Key: SLING-8946
> URL: https://issues.apache.org/jira/browse/SLING-8946
> Project: Sling
> Issue Type: Bug
> Components: ResourceResolver
> Affects Versions: Resource Resolver 1.5.34
> Reporter: Dirk Rudolph
> Assignee: Robert Munteanu
> Priority: Critical
> Fix For: Resource Resolver 1.6.18
>
> Attachments: PerformanceScript.sh
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> The BasicObservationReporter implements shadowing of events being propagated
> per ResourceProvider instance [1]. Assuming we do have 2 ResourceProviders
> registered, where the one shadows the other like this:
> - RP A registered on /
> - RP B registered on /path
> then currently the excludes given to the BasicObservationReporter are
> different depending on either RP A or RP B gets registered first:
> - RP A before RP B => excludes are empty
> - RP B before RP A => excludes contain /path
> This is because only the newly registered RP gets its ProviderContext updated
> [2]
> Same applies if RP B is registered before RP A and gets unregistered. In that
> case the ObservationReporter of RP A stays untouched.
> [1]
> [https://github.com/apache/sling-org-apache-sling-resourceresolver/blob/master/src/main/java/org/apache/sling/resourceresolver/impl/observation/BasicObservationReporter.java#L102]
> [2]
> [https://github.com/apache/sling-org-apache-sling-resourceresolver/blob/master/src/main/java/org/apache/sling/resourceresolver/impl/providers/ResourceProviderTracker.java#L358]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
