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

Felix Meschberger resolved FELIX-1658.
--------------------------------------

    Resolution: Fixed

Removed synchronization from the internal state changing methods in Rev. 
830886. To try to prevent concurrent state changing actions, I introduced 
transient states which are set at the begining of changing the state. The 
transient states do nothing and thus prevent concurrent state changes.

An issue, which might arise from this is, that there may be situations where a 
required state change might get lost. For example if the Activator Thread is 
activating a component (thus the component is in the ACITVATING state) and at 
the same time a service registration event would cause the component to have to 
be deactivated. This might get lost.

For now, I think we are pretty much ok and a workaround is to manually 
disable/enable the respective component in such cases. As soon as we have a 
reproducable issue we can try to find a solution, for example to be able to 
"abort" acitvation to wait for the activation to terminate before continuing 
with deactivation -- though this then has the potential for deadlock again...

> Deadlocks caused by component activation and deactivation
> ---------------------------------------------------------
>
>                 Key: FELIX-1658
>                 URL: https://issues.apache.org/jira/browse/FELIX-1658
>             Project: Felix
>          Issue Type: Bug
>          Components: Declarative Services (SCR)
>    Affects Versions: scr-1.2.0
>            Reporter: Felix Meschberger
>            Assignee: Felix Meschberger
>             Fix For: scr-1.2.0
>
>
> Deadlock issues with SCR: Component operations are synchronized and may run 
> while the bundle lock is held. This may cause deadlocks with the framework 
> (mostly between the PackageAdmin thread and the SCR Component Actor thread).
> The problem is that many operations of SCR are called in a bundle listener 
> and cause further operations (while holding Java locks (synchronized)) inside 
> the framework.

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

Reply via email to