You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Felix Meschberger (JIRA)" <ji...@apache.org> on 2007/10/01 09:20:50 UTC

[jira] Resolved: (FELIX-384) Possible deadlock on framework startlevel change

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

Felix Meschberger resolved FELIX-384.
-------------------------------------

    Resolution: Fixed

Taking service registration out of the synchronization on the component manager instance in the AbstractComponentManager.activateInternal method should fix this issue in the Felix implementation.

While this fix targets the Felix framework implementation, I assume, this does not harm any other framework implementation but may prevent similar issues in them.

Fixed in Rev. 580873.

Will close the issue, when deploying a snapshot

> Possible deadlock on framework startlevel change
> ------------------------------------------------
>
>                 Key: FELIX-384
>                 URL: https://issues.apache.org/jira/browse/FELIX-384
>             Project: Felix
>          Issue Type: Bug
>          Components: Declarative Services
>            Reporter: Felix Meschberger
>            Assignee: Felix Meschberger
>            Priority: Critical
>             Fix For: 1.0.0
>
>
> Felix SCR uses java synchronization on component manager instances to prevent synchronous execution of certain actions like activation and deactivation. In concert with the locking implemented by the Felix framework, deadlocks may occurr in certain situations.
> For example: If the framework has been started but the SCR Activator queue still has a deadlock and the framework is instructed to shutdown.
> The start level service will now stop bundles in the FelixStartLevel thread. At one point in time Bundle X will be stopped and the framework holds the bundle lock while stopping the bundle. Stopping the bundle causes a synchronous STOPPING event being handled by the SCR, which causes immediate deactivation of all components of the bundle. This causes the AbstractComponentManager.deactivateInternal method to be called which is synchronized on the instance.
> At the same time, the components of Bundle X may still be scheduled for activation in the SCR Activator queue handled by the  SCR Component Actor thread. This thread may be activating a component of Bundle X trying to register the component as a service in the AbstractComponentManager.activateInternal method (synchronized on the instance). Registering the service tries to acquire the bundle lock first.
> The result is a deadlock between the FelixStartLevel thread (holding the bundle lock and waiting for the component manager lock) and the SCR Component Actor thread (holding the component lock and waiting for the bundle lock).
> While this is probably a seldom situation, it must be prevent from happening nevertheless.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.