felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jad Naous (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (FELIX-3839) iPOJO deadlocks on a bundle refresh
Date Tue, 08 Jan 2013 14:10:12 GMT

    [ https://issues.apache.org/jira/browse/FELIX-3839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13546910#comment-13546910
] 

Jad Naous edited comment on FELIX-3839 at 1/8/13 2:09 PM:
----------------------------------------------------------

Also, I fixed the NPE raised. It was a bug in the bundlerrepository implementation (or so
it seems). Opening another bug report for that. That also resolves the multiple instances
of components.
                
      was (Author: jnaous):
    Also, I fixed the NPE raised. It was a bug in the bundlerrepository implementation (or
so it seems). Opening another bug report for that.
                  
> iPOJO deadlocks on a bundle refresh
> -----------------------------------
>
>                 Key: FELIX-3839
>                 URL: https://issues.apache.org/jira/browse/FELIX-3839
>             Project: Felix
>          Issue Type: Bug
>          Components: iPOJO
>    Affects Versions: ipojo-core-1.8.4, ipojo-runtime-1.8.6
>            Reporter: Jad Naous
>            Assignee: Clement Escoffier
>             Fix For: ipojo-runtime-1.8.6
>
>
> iPOJO grabs a number of locks during synchronous callbacks from the framework, some in
InstanceCreator and some in IPojoFactory. This can cause a repeatable deadlock situation during
service registration (which attempts to grab the global felix framework lock, fixed in FELIX-3761)
or during class resolution (still a problem). iPOJO should not be grabbing any locks during
callbacks from the framework because those callbacks may be holding framework locks, and if
another thread invokes the framework while holding the same lock, a deadlock will result.
Below are stack traces two deadlock situations.
> Here's the stack trace that causes the deadlock in the first situation, which happens
before FELIX-3761, but really shouldn't happen with or without that fix:
> Daemon Thread [Thread-1] (Suspended)	
> 	Object.wait(long) line: not available [native method]	
> 	Object[](Object).wait() line: 485	
> 	Felix.acquireBundleLock(BundleImpl, int) line: 4871	
> 	Felix.registerService(BundleImpl, String[], Object, Dictionary) line: 3205	
> 	BundleContextImpl.registerService(String[], Object, Dictionary) line: 346	
> 	IPojoContext.registerService(String[], Object, Dictionary) line: 385	
> 	ProvidedService.registerService() line: 362	
> 	ProvidedServiceHandler.__M_stateChanged(int) line: 509	
> 	ProvidedServiceHandler.stateChanged(int) line: not available	
> 	InstanceManager.setState(int) line: 536	
> 	InstanceManager.start() line: 418	
> 	ComponentFactory.createInstance(Dictionary, IPojoContext, HandlerManager[]) line: 179

> 	ComponentFactory(IPojoFactory).createComponentInstance(Dictionary, ServiceContext) line:
310	
> 	ComponentFactory(IPojoFactory).createComponentInstance(Dictionary) line: 239	
> 	InstanceCreator$ManagedInstance.create(IPojoFactory) line: 355	
> 	InstanceCreator.addInstance(Dictionary, long) line: 89	
> 	Extender.parse(Bundle, String) line: 306	
> 	Extender.startManagementFor(Bundle) line: 237	
> 	Extender.access$600(Extender, Bundle) line: 52	
> 	Extender$CreatorThread.run() line: 769	
> 	Thread.run() line: 662	
> Daemon Thread [FelixFrameworkWiring] (Suspended)	
> 	InstanceCreator.removeInstancesFromBundle(long) line: 116	
> 	Extender.closeManagementFor(Bundle) line: 171	
> 	Extender.bundleChanged(BundleEvent) line: 153	
> 	EventDispatcher.invokeBundleListenerCallback(Bundle, EventListener, EventObject) line:
868	
> 	EventDispatcher.fireEventImmediately(EventDispatcher, int, Map, EventObject, Dictionary)
line: 789	
> 	EventDispatcher.fireBundleEvent(BundleEvent, Framework) line: 514	
> 	Felix.fireBundleEvent(int, Bundle) line: 4244	
> 	Felix.stopBundle(BundleImpl, boolean) line: 2351	
> 	Felix$RefreshHelper.stop() line: 4629	
> 	Felix.refreshPackages(Collection, FrameworkListener[]) line: 3951	
> 	FrameworkWiringImpl.run() line: 172	
> 	Thread.run() line: 662
> Here's the stack trace for the other situation caused by class resolution in the framework:
> Name: Thread-2
> State: WAITING on [Ljava.lang.Object;@4a018e1b
> Total blocked: 38,871,649  Total waited: 38,871,650
> Stack trace: 
>  java.lang.Object.wait(Native Method)
> java.lang.Object.wait(Object.java:485)
> org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:5033)
> org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:451)
> org.apache.felix.framework.BundleWiringImpl.searchDynamicImports(BundleWiringImpl.java:1578)
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1478)
> org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:75)
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1882)
> java.lang.ClassLoader.loadClass(ClassLoader.java:247)
> org.apache.felix.framework.BundleWiringImpl.getClassByDelegation(BundleWiringImpl.java:1356)
> org.apache.felix.framework.ServiceRegistrationImpl$ServiceReferenceImpl.isAssignableTo(ServiceRegistrationImpl.java:548)
> org.apache.felix.framework.util.Util.isServiceAssignable(Util.java:280)
> org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:916)
> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793)
> org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543)
> org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4346)
> org.apache.felix.framework.Felix.registerService(Felix.java:3356)
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:346)
> org.apache.felix.ipojo.IPojoFactory.start(IPojoFactory.java:613)
>    - locked org.apache.felix.ipojo.ComponentFactory@468034b6
> org.apache.felix.ipojo.Extender.createAbstractFactory(Extender.java:520)
> org.apache.felix.ipojo.Extender.parse(Extender.java:301)
> org.apache.felix.ipojo.Extender.startManagementFor(Extender.java:237)
> org.apache.felix.ipojo.Extender.access$600(Extender.java:52)
> org.apache.felix.ipojo.Extender$CreatorThread.run(Extender.java:769)
> java.lang.Thread.run(Thread.java:662)
> Name: FelixFrameworkWiring
> State: BLOCKED on org.apache.felix.ipojo.ComponentFactory@468034b6 owned by: Thread-2
> Total blocked: 7  Total waited: 1
> Stack trace: 
> org.apache.felix.ipojo.IPojoFactory.removeFactoryStateListener(IPojoFactory.java:511)
> org.apache.felix.ipojo.InstanceCreator.removeFactory(InstanceCreator.java:199)
> org.apache.felix.ipojo.Extender.closeManagementFor(Extender.java:180)
> org.apache.felix.ipojo.Extender.bundleChanged(Extender.java:153)
> org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:868)
> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:789)
> org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:514)
> org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4330)
> org.apache.felix.framework.Felix.stopBundle(Felix.java:2451)
> org.apache.felix.framework.Felix$RefreshHelper.stop(Felix.java:4715)
> org.apache.felix.framework.Felix.refreshPackages(Felix.java:4037)
> org.apache.felix.framework.FrameworkWiringImpl.run(FrameworkWiringImpl.java:178)
> java.lang.Thread.run(Thread.java:662)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message