sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dirk Rudolph (Jira)" <>
Subject [jira] [Commented] (SLING-8946) Non-deterministic shadowing of resource observation
Date Thu, 25 Jun 2020 13:39:00 GMT


Dirk Rudolph commented on SLING-8946:

*TLDR* If SLING-9365 remains an optional opt-in we have to expect a higher startup time of
a Sling applications registering a arge amount of scripts/servlets. However the project his
issue was facing already change direction towards a different approach, getting rid of the
custom ResourceProvider implementation at all. So I'm also fine if we revert the changes and
keep this open. wdyt?

As said before the functional defect addressed here, has been resolved. The performance problems
reported by [~sonagupt] are related to AEM which apparently registers more than 1000 ResourceResolvers.
The logic does not scale well for that amount and as explained before the registered ResourceProviders
are iterated with a polynomial time complexity. SLING-9040 addressed one of those iterations
and SLING-9077 was supposed to address another. Still it would not resolve the problem when
scaling to 10s of thousands of ResourceProviders. SLING-9365 simply addresses this problem
from a different angle by not registering the (thousands of) ServletResourceProviders in the
first place. 

Afaics the failing tests were simply caused by timeouts during the setup of the integration

> Non-deterministic shadowing of resource observation
> ---------------------------------------------------
>                 Key: SLING-8946
>                 URL:
>             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:
>          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] []
>  [2] []

This message was sent by Atlassian Jira

View raw message