[
https://issues.apache.org/jira/browse/FELIX-490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger closed FELIX-490.
-----------------------------------
Resolution: Fixed
Fix Version/s: scr-1.0.1
Assignee: Felix Meschberger
In Rev. 662733 of the AbstractCompeontManager class I modified the deactivate()
method to call the deactivateInternal immediately unless the component is
currently being activated. In this case deactivation is scheduled for
asynchronous execution and a info (Rev. 662734, was WARN initially) is printed.
This should solve this deadlock, as the deactivateInternal method is only
called from the separate thread and thus needs not waiting on the
activateInternal method to finish, which in turn might be wait for the service
registration event call causing the deactivation to terminate.
> Deadlocks may be caused by Declarative Services
> -----------------------------------------------
>
> Key: FELIX-490
> URL: https://issues.apache.org/jira/browse/FELIX-490
> Project: Felix
> Issue Type: Bug
> Components: Declarative Services (SCR)
> Affects Versions: felix-1.0.0
> Reporter: Felix Meschberger
> Assignee: Felix Meschberger
> Fix For: scr-1.0.1
>
> Attachments: threaddump.txt
>
>
> The Declarative Services implementation has an AbstractComponentManager class
> which implementa the lifecycles of components in methods like enable,
> activate, deactivate, disable and dispose. All methods come in two flavors an
> (private) internal on which is synchronized and executes the action and a
> public unsynchronized one calling the internal one on a separate thread.
> All internal methods are generally called only from the separate thread so
> are guaranteed to run sequentially on after the other due to the queing in
> the thread. One exception is the deactivate method which is always called
> directly and not in the separate thread. So a component may be deactivated
> while it is actually being activated. This is why the internal methods are
> synchronized - to delay a deactivation in case an activation already active.
> The problem is, that activate calls in to the framework to get at services or
> to register services. At the same time the deactivate method may be called
> from within the framework for example because a required or static dependency
> has been unregistered. This may now create a deadlock between the activate
> method trying to register a service and the service unregistration trying to
> call the deactivate method.
> The fix is to look at a more finegrained synchronization mechanism in the
> AbstractComponentManager.
> Similar behaviour is reported in FELIX-489, which is currently analysed
> looking from the framework to the outside.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
