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

Felix Meschberger closed FELIX-911.
-----------------------------------


Thanks alot. This looks good to me and it also works in my tests.

> Potential deadlock between Bundle.stop() and BundleContext.registerService()
> ----------------------------------------------------------------------------
>
>                 Key: FELIX-911
>                 URL: https://issues.apache.org/jira/browse/FELIX-911
>             Project: Felix
>          Issue Type: Bug
>          Components: Framework
>    Affects Versions: felix-1.0.0, felix-1.0.1, felix-1.0.3, felix-1.0.4, 
> felix-1.2.0, felix-1.2.1
, felix-1.2.2, felix-1.4.0, felix-1.4.1, felix-1.6.0
>            Reporter: Felix Meschberger
>            Assignee: Richard S. Hall
>             Fix For: felix-1.6.0
>
>         Attachments: FELIX-911.patch
>
>
> When a bundle tries to register a service (in thread T1) and the framework is 
> at the same time stopping the bundle (in thread T2), it may be that thread T2 
> holds the bundle's lock. T1 trying to register the service is thus blocked 
> since it cannot get the bundle lock.
> This may cause a deadlock in Felix SCR, which also works with synchronized 
> instances: T1 may be SCR Actor thread starting a component and registering a 
> service and thus holding a lock on the component instance. T2 may be the 
> StartLevel service trying to stop the bundle, which causes the SCR to 
> immediately stop the component. Since the component is locked by T1, T2 
> cannot acquire the lock. But since T2 already has the bundle lock, T1 cannot 
> continue.
> The problem is, that in this concrete case it is the Component's activate() 
> method which registers the service and not the SCR ComponentManager (the 
> latter deadlock situation has been taken care of in FELIX-384).
> Looking at the code of Felix.registerService it looks like we could check for 
> the bundle state before holding the bundle lock (and we could recheck after
> the lock just to be sure, if needed) and thus prevent the deadlock situation.

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