[
https://issues.apache.org/jira/browse/FELIX-911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12669693#action_12669693
]
Felix Meschberger commented on FELIX-911:
-----------------------------------------
> The main issue with the patch is that it only narrows the possibility of a
> deadlock.
Unfortunately, yes.
> I think I have an idea on how we could eliminate it in this situation, so I
> will try to look into it this week.
Cool. Thanks.
> 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.
