felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dieter Wimberger (JIRA)" <j...@apache.org>
Subject [jira] Closed: (FELIX-536) Threadlocks on ContentClassLoader by FelixDispatchQueue and FelixStartLevel threads when using log bundles
Date Mon, 14 Apr 2008 05:49:04 GMT

     [ 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/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.


Mime
View raw message