[ 
https://issues.apache.org/jira/browse/SLING-12382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Ziegeler resolved SLING-12382.
--------------------------------------
    Resolution: Fixed

Rewrote the resource provider handling in 
https://github.com/apache/sling-org-apache-sling-resourceresolver/commit/a3eb20f55bef0620aa22d7afbbe1c980376e6a10

The resource provider service is fetched from the registry directly on 
registration within the tracker and only released once the tracker is informed 
about the unregister event. This way all calls to the service registry are 
outside of a sync block. Under normal operations there is no real difference in 
how services are get/unget.

Cleaned up the code based on this new handling

> 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)

Reply via email to