[
https://issues.apache.org/jira/browse/FELIX-490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger updated FELIX-490:
------------------------------------
Attachment: threaddump.txt
Thread dump showing this deadlock. This dump has been attached to SLING-245.
> 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
> Affects Versions: 1.0.0
> Reporter: Felix Meschberger
> 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.
