[jira] [Comment Edited] (FELIX-3067) Prevent Deadlock Situation in Felix.acquireGlobalLock

["metatech (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/FELIX-3067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14219146#comment-14219146 ] 

metatech edited comment on FELIX-3067 at 11/20/14 9:14 AM:
-----------------------------------------------------------

The following steps helped to strongly mitigate the likelihood that the problems occurs, although none of them solved the root case.
1. Remove all "DynamicImport-Package" directives from bundles deployed in the "deploy" directory. This is due to the "searchDynamicImports" method which needs the global lock.
2. Remove the "OsgiThrowableRenderer" from the config file "org.ops4j.pax.logging.cfg".
3. Migrate all the bundles in the "deploy" from Spring XML to Blueprint XML and use the property "org.apache.aries.blueprint.synchronous=false".
4. Deploy bundles in the "deploy" directory only when ServiceMix is started, and not when it is stopped.  Otherwise, the deadlocks appears shortly after the "forgetUninstalledBundle" is called.
5. Use 2 DirectoryWatcher (with patch FELIX-4661), one at start-level 80 for all "libraries" bundles and one at start-level 85 for all "applications" bundles.  Also, adding one "test" application at level 80 might help, to do a "pre-initialization" before all real bundles are started.


was (Author: metatech):
The following steps helped to strongly mitigate the likelihood that the problems occurs, although none of them solved the root case.
1. Remove all "DynamicImport-Package" directives from bundles deployed in the "deploy" directory. This is due to the "searchDynamicImports" method which needs the global lock.
2. Remove the "OsgiThrowableRenderer" from the config file "org.ops4j.pax.logging.cfg".
3. Migrate all the bundles in the "deploy" from Spring XML to Blueprint XML.
4. Deploy bundles in the "deploy" directory only when ServiceMix is started, and not when it is stopped.  Otherwise, the deadlocks appears shortly after the "forgetUninstalledBundle" is called.

> Prevent Deadlock Situation in Felix.acquireGlobalLock
> -----------------------------------------------------
>
>                 Key: FELIX-3067
>                 URL: https://issues.apache.org/jira/browse/FELIX-3067
>             Project: Felix
>          Issue Type: Improvement
>          Components: Framework
>    Affects Versions: framework-3.0.7, framework-3.0.8, framework-3.0.9, framework-3.2.0, framework-3.2.1, fileinstall-3.1.10
>            Reporter: Felix Meschberger
>         Attachments: FELIX-3067-sling.patch, FELIX-3067.patch, felix_unblock_deadlock.patch, felix_unblock_deadlock_2.patch, felix_unblock_deadlock_v2.patch, felix_unblock_deadlock_v4.patch, threaddump-ise-deadlock.txt, threads_locked_by_camel_type_converter
>
>
> Every now and then we encounter deadlock situations which involve the Felix.acquireGlobalLock method. In our use case we have the following aspects which contribute to this:
> (a) The Apache Felix Declarative Services implementation stops components (and thus causes service unregistration) while the bundle lock is being held because this happens in a SynchronousBundleListener while handling the STOPPING bundle event. We have to do this to ensure the bundle is not really stopped yet to properly stop the bundle's components.
> (b) Implementing a special class loader which involves dynamically resolving packages which in turn uses the global lock
> (c) Eclipse Gemini Blueprint implementation which operates asynchronously
> (d) synchronization in application classes
> Often times, I would assume that we can self-heal such complex deadlck situations, if we let acquireGlobalLock time out. Looking at the calles of acquireGlobalLock there seems to already be provision to handle this case since acquireGlobalLock returns true only if the global lock has actually been acquired.
> This issue is kind of a companion to FELIX-3000 where deadlocks involve sending service registration events while holding the bundle lock.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)