[
https://issues.apache.org/jira/browse/FELIX-3067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14054976#comment-14054976
]
metatech commented on FELIX-3067:
---------------------------------
There is a variant of the problem with "acquireBundleLock" (instead of
"acquireGlobalLock").
It happens when a "base" bundle is redeployed in "deploy" directory.
The "FelixStartLevel" starts to loop forever with the following the stack trace
:
{code}
"FelixStartLevel" daemon prio=5 Thread id=11 RUNNABLE
java.lang.Throwable.fillInStackTrace(Native Method)
java.lang.Throwable.fillInStackTrace(Throwable.java:783)
java.lang.Throwable.<init>(Throwable.java:265)
java.lang.Exception.<init>(Exception.java:50)
java.lang.RuntimeException.<init>(RuntimeException.java:62)
java.lang.IllegalStateException.<init>(IllegalStateException.java:55)
org.apache.felix.framework.Felix.acquireBundleLock(Felix.java:4955)
org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1156)
org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:266)
java.lang.Thread.run(Thread.java:745)
{code}
> 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, 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.2#6252)
