[
https://issues.apache.org/jira/browse/SLING-12382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17865863#comment-17865863
]
Carsten Ziegeler commented on SLING-12382:
------------------------------------------
Fixed the handling of modifed events
https://github.com/apache/sling-org-apache-sling-resourceresolver/commit/d33a37c0c25fa7944692dc08515d6d0d5790cba1
> 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)
