felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Karl Pauls (JIRA)" <j...@apache.org>
Subject [jira] Assigned: (FELIX-536) Threadlocks on ContentClassLoader by FelixDispatchQueue and FelixStartLevel threads when using log bundles
Date Sun, 13 Apr 2008 20:55:05 GMT

     [ https://issues.apache.org/jira/browse/FELIX-536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Karl Pauls reassigned FELIX-536:
--------------------------------

    Assignee: Karl Pauls

> 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
>
> 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