[
https://issues.apache.org/jira/browse/SLING-11754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17680946#comment-17680946
]
Michal Cukierman edited comment on SLING-11754 at 1/26/23 10:49 AM:
--------------------------------------------------------------------
In other words, SortingServiceTracker invokes: `scheduleRetry` in the new
thread.
[https://github.com/apache/sling-org-apache-sling-installer-core/blob/|https://github.com/apache/sling-org-apache-sling-installer-core/blob/cf05c81bb063ff8a19ffd083d6e1a175b630abc5/src/main/java/org/apache/sling/installer/core/impl/SortingServiceTracker.java#L87]
[master|https://github.com/apache/sling-org-apache-sling-installer-core/blob/master/src/main/java/org/apache/sling/installer/core/impl/SortingServiceTracker.java#L126]
[/src/main/java/org/apache/sling/installer/core/impl/SortingServiceTracker.java#L87|https://github.com/apache/sling-org-apache-sling-installer-core/blob/cf05c81bb063ff8a19ffd083d6e1a175b630abc5/src/main/java/org/apache/sling/installer/core/impl/SortingServiceTracker.java#L87]
The new thread depends on the state of the same service tracker:
[https://github.com/apache/sling-org-apache-sling-installer-core/blob/master/src/main/java/org/apache/sling/installer/core/impl/SortingServiceTracker.java#L126]
-I guess the simplest solution would be to override and synchronize:-
-SortingServiceTracker.addingService (which updates the state of the object)-
-SortingServiceTracker.getTrackingCount (which uses the state of the object
from the other thread)-
-and eventually:-
-SortingServiceTracker.getServiceReferences (which updates the state of the
object)-
-This is definitely not a best solution, but should work. What do you think?-
Looks like the solutions is too naive ;)
was (Author: michalcukierman):
In other words, SortingServiceTracker invokes: `scheduleRetry` in the new
thread.
[https://github.com/apache/sling-org-apache-sling-installer-core/blob/|https://github.com/apache/sling-org-apache-sling-installer-core/blob/cf05c81bb063ff8a19ffd083d6e1a175b630abc5/src/main/java/org/apache/sling/installer/core/impl/SortingServiceTracker.java#L87]
[master|https://github.com/apache/sling-org-apache-sling-installer-core/blob/master/src/main/java/org/apache/sling/installer/core/impl/SortingServiceTracker.java#L126]
[/src/main/java/org/apache/sling/installer/core/impl/SortingServiceTracker.java#L87|https://github.com/apache/sling-org-apache-sling-installer-core/blob/cf05c81bb063ff8a19ffd083d6e1a175b630abc5/src/main/java/org/apache/sling/installer/core/impl/SortingServiceTracker.java#L87]
The new thread depends on the state of the same service tracker:
[https://github.com/apache/sling-org-apache-sling-installer-core/blob/master/src/main/java/org/apache/sling/installer/core/impl/SortingServiceTracker.java#L126]
I guess the simplest solution would be to override and synchronize:
SortingServiceTracker.addingService (which updates the state of the object)
SortingServiceTracker.getTrackingCount (which uses the state of the object from
the other thread)
and eventually:
SortingServiceTracker.getServiceReferences (which updates the state of the
object)
This is definitely not a best solution, but should work. What do you think?
> Race condition in OsgiInstaller
> -------------------------------
>
> Key: SLING-11754
> URL: https://issues.apache.org/jira/browse/SLING-11754
> Project: Sling
> Issue Type: Bug
> Components: Installer
> Affects Versions: Installer Packages Factory 1.0.4, Installer Core 3.12.0
> Reporter: Pawe�� Boguski
> Priority: Major
>
> [OsgiInstallerImpl|https://github.com/apache/sling-org-apache-sling-installer-core/blob/master/src/main/java/org/apache/sling/installer/core/impl/OsgiInstallerImpl.java#L143]
> is using
> [SortingServiceTracker|https://github.com/apache/sling-org-apache-sling-installer-core/blob/master/src/main/java/org/apache/sling/installer/core/impl/SortingServiceTracker.java#L87]
> to schedule a retry of the OSGi installer run when new service of type
> ResourceTransformer is added. During the OSGi installer run, the list of
> available ResourceTransformer services is loaded to [transform
> resources|https://github.com/apache/sling-org-apache-sling-installer-core/blob/master/src/main/java/org/apache/sling/installer/core/impl/OsgiInstallerImpl.java#L953].
>
> It might happen that the list of available ResourceTransformer services will
> be loaded during transforming resources before the new ResourceTransformer
> which triggered the OSGi installer run will be available in the
> SortingServiceTracker instance, because the scheduleRetry call is done in
> SortingServiceTracker.addingService not when the service is already available
> in SortingServiceTracker but during the preparation of the service instance
> (the instance returned from SortingServiceTracker.addingService is later
> added to services list in SortingServiceTracker).
> So in other words, there is a race condition between adding a new service
> instance to SortingServiceTracker services list and OSGi installer run which
> perform getting the instances of ResourceTransformer services from the
> SortingServiceTracker.
> In the result activation of ResourceTransformer might trigger the OSGi
> installer run but the service will not be found during the run.
> Example issue caused by this:
> If such a last OSGi installer run would be caused by activation of
> [PackageTransformer|https://github.com/apache/sling-org-apache-sling-installer-core/blob/master/src/main/java/org/apache/sling/installer/core/impl/OsgiInstallerImpl.java#L953]
> the untransformed content packages (for example added by OSGI feature model
> during the first start of the instance) stays untransformed.
> In our pipelines for PRs validation this is happening very often.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
