[
https://issues.apache.org/jira/browse/FELIX-536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dieter Wimberger closed FELIX-536.
----------------------------------
Stuart:
I guess I have to agree, but I think it's a bit counter-intuitive.
The question that remains open is, whether there is a way to debug classloading
and wiring if these debugs are simply turned off.
Maybe there should be a way to log these without depending on the presence of
an special (because it will need to avoid the deadlocks) LogService (which is
part of the compendium, not the core specs).
But then, that may be a new feature request, so I better close this issue.
Regards,
Dieter
> 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.
