[
https://issues.apache.org/jira/browse/SLING-12382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17865373#comment-17865373
]
Carsten Ziegeler edited comment on SLING-12382 at 7/13/24 11:51 AM:
--------------------------------------------------------------------
I re-introduced the larger synchronized blocks to make sure that
adding/removing a resource provider is handled correctly
In addition, the change listener (rr factory) is only updated once for each
operation - which is actually a plus and can reduce churn in the system.
https://github.com/apache/sling-org-apache-sling-resourceresolver/commit/23d16d1d047250ca834b1960cb908d293f3bcbe7
https://github.com/apache/sling-org-apache-sling-resourceresolver/commit/3b890d275786079b8086027f31b1cb5a0362c2a8
https://github.com/apache/sling-org-apache-sling-resourceresolver/commit/7bf75d45d7da49b51c985fbd6dfc933d5a1b55f6
was (Author: cziegeler):
I re-introduced the larger synchronized blocks to make sure that
adding/removing a resource provider is handled correctly
In addition, the change listener (rr factory) is only updated once for each
operation - which is actually a plus and can reduce churn in the system.
https://github.com/apache/sling-org-apache-sling-resourceresolver/commit/23d16d1d047250ca834b1960cb908d293f3bcbe7
> Potential concurrency issues with resource provider
> registration/unregistration
> -------------------------------------------------------------------------------
>
> Key: SLING-12382
> URL: https://issues.apache.org/jira/browse/SLING-12382
> Project: Sling
> Issue Type: Bug
> Components: ResourceResolver
> Affects Versions: Resource Resolver 1.11.6
> Reporter: Carsten Ziegeler
> Assignee: Carsten Ziegeler
> Priority: Major
> Fix For: Resource Resolver 1.12.0
>
>
> With SLING-6943 (and follow up issues) we removed larger synchronized blocks
> in favour if smaller ones to not call to the service registry from within a
> synchronized blocks.
> However, this split up synchronization might lead to concurrency issues - the
> code that got split up into smaller sync blocks still expects that no one
> interferes while all the blocks are executed.
> As that might happen, this results in the code making wrong expectations.
> We probably need to get back to large sync'ed blocks and call the service
> registry from within.
> Update: the code is actually written with the exceptional case in mind (two
> providers for the same path) - only for that case the lazy getting of
> services makes sense. As the normal use case requires the service anyway, we
> can avoid calling to the service registry from within the sync blocks -
> punishing the exceptional case with potentially unnecessary fetched providers
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
