You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Karl Pauls (JIRA)" <ji...@apache.org> on 2008/04/13 23:27:04 UTC
[jira] Resolved: (FELIX-536) Threadlocks on ContentClassLoader by
FelixDispatchQueue and FelixStartLevel threads when using log bundles
[ 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/dev@felix.apache.org/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.