[
https://issues.apache.org/jira/browse/FELIX-3067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14312259#comment-14312259
]
metatech commented on FELIX-3067:
---------------------------------
On top of the 5 measures given in a previous comment :
6. Add "org.xml.sax,com.sun.xml.bind.v2.runtime.reflect" in the
"Import-Package" section of the MANIFEST.MF for camel-core, camel-blueprint,
and camel-spring. This workaround solves the JAXB deadlock when calling
"com.sun.xml.bind.v2.runtime.reflect.opt.Injector", which retrieves the
"Accessor" class by loading the class explicitly from the parent classloader (I
think JAXB behiavour is not very OSGi-friendly). This allows JAXB to find the
"Accessor", without falling back to search in the dynamic imports.
> 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)
