[
https://issues.apache.org/jira/browse/FELIX-536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls resolved FELIX-536.
------------------------------
Resolution: Fixed
Fix Version/s: felix-1.0.4
The issue is that we log messages while holding framework internal locks --
hence, when a log service calls back into the framework (e.g., by loading a
class) we might deadlock. This is one instance of this problem.
I disabled logging to internal log services - we can reintroduce this feature
at a later time but - for now it is clear that people keep running into this
issue and all we are trying is to be nice.
Please close this issue if the current trunk works for you.
> Threadlocks on ContentClassLoader by FelixDispatchQueue and FelixStartLevel
> threads when using log bundles
> ----------------------------------------------------------------------------------------------------------
>
> Key: FELIX-536
> URL: https://issues.apache.org/jira/browse/FELIX-536
> Project: Felix
> Issue Type: Bug
> Affects Versions: felix-1.0.3
> Environment: 1.6.0_03-b05;Sun Microsystems Inc.;mixed mode,
> sharing;Linux;32 bit JVM
> and
> 1.5.0_13-119;Apple Inc.;mixed mode, sharing;Mac OS X;32 bit JVM
> Reporter: Dieter Wimberger
> Assignee: Karl Pauls
> Priority: Blocker
> Fix For: felix-1.0.4
>
>
> Sometimes Felix gets stuck at startup with a threadlock when using a log
> bundle, including the Felix provided log bundle.
> jdb reveals the following information:
> FelixDispatchQueue[1] threadlocks 0x3c1
> Monitor information for thread FelixDispatchQueue:
> Owned monitor: instance of
> org.apache.felix.framework.searchpolicy.ContentClassLoader(id=970)
> Waiting for monitor: instance of
> org.apache.felix.moduleloader.ModuleFactoryImpl(id=971)
> FelixDispatchQueue[1] threadlocks 0x3c0
> Monitor information for thread FelixStartLevel:
> Owned monitor: instance of
> org.apache.felix.moduleloader.ModuleFactoryImpl(id=971)
> Waiting for monitor: instance of
> org.apache.felix.framework.searchpolicy.ContentClassLoader(id=970)
> FelixStartLevel[1] where
> [1] sun.misc.Unsafe.defineClass (native method)
> [2] sun.reflect.ClassDefiner.defineClass (ClassDefiner.java:45)
> [3] sun.reflect.MethodAccessorGenerator$1.run
> (MethodAccessorGenerator.java:381)
> [4] java.security.AccessController.doPrivileged (native method)
> [5] sun.reflect.MethodAccessorGenerator.generate
> (MethodAccessorGenerator.java:377)
> [6] sun.reflect.MethodAccessorGenerator.generateMethod
> (MethodAccessorGenerator.java:59)
> [7] sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:28)
> [8] sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:25)
> [9] java.lang.reflect.Method.invoke (Method.java:585)
> [10] org.apache.felix.framework.Logger._logReflectively (Logger.java:163)
> [11] org.apache.felix.framework.Logger._log (Logger.java:143)
> [12] org.apache.felix.framework.Logger.log (Logger.java:81)
> [13] org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.createWires
> (R4SearchPolicyCore.java:2,154)
> [14] org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.resolve
> (R4SearchPolicyCore.java:1,034)
> [15] org.apache.felix.framework.Felix._resolveBundle (Felix.java:1,693)
> [16] org.apache.felix.framework.Felix._startBundle (Felix.java:1,566)
> [17] org.apache.felix.framework.Felix.startBundle (Felix.java:1,519)
> [18] org.apache.felix.framework.Felix.setFrameworkStartLevel
> (Felix.java:1,104)
> [19] org.apache.felix.framework.StartLevelImpl.run (StartLevelImpl.java:258)
> [20] java.lang.Thread.run (Thread.java:613)
> FelixDispatchQueue[1] where
> [1] org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.resolve
> (R4SearchPolicyCore.java:989)
> [2]
> org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.findClassOrResource
> (R4SearchPolicyCore.java:374)
> [3] org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.findClass
> (R4SearchPolicyCore.java:186)
> [4] org.apache.felix.framework.searchpolicy.R4SearchPolicy.findClass
> (R4SearchPolicy.java:45)
> [5] org.apache.felix.framework.searchpolicy.ContentClassLoader.loadClass
> (ContentClassLoader.java:109)
> [6] java.lang.ClassLoader.loadClass (ClassLoader.java:251)
> [7] java.lang.ClassLoader.loadClassInternal (ClassLoader.java:374)
> I have been reading
> http://www.mail-archive.com/[email protected]/msg03142.html
> But I think that it does not really provide a "solution" to this problem and
> that this is an issue in the framework implementation. I don't think that the
> specification of the LogService implies that it cannot be configurable or
> loading any classes.....
> Regards,
> Dieter
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
