You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Paolo Antinori (JIRA)" <ji...@apache.org> on 2017/04/10 11:26:41 UTC

[jira] [Created] (FELIX-5612) [SCR] Deadlock while invoking SCR api from lifecycle methods

Paolo Antinori created FELIX-5612:
-------------------------------------

             Summary: [SCR] Deadlock while invoking SCR api from lifecycle methods
                 Key: FELIX-5612
                 URL: https://issues.apache.org/jira/browse/FELIX-5612
             Project: Felix
          Issue Type: Bug
          Components: Declarative Services (SCR)
         Environment: {code}
JBossFuse:karaf@root> la -l | grep felix
[   9] [Active     ] [            ] [   80] mvn:org.apache.felix/org.apache.felix.configadmin/1.8.12
[  10] [Active     ] [            ] [   80] mvn:org.apache.felix/org.apache.felix.fileinstall/3.5.8
[  12] [Active     ] [            ] [   80] mvn:org.apache.felix/org.apache.felix.metatype/1.0.10
[ 153] [Active     ] [            ] [   30] mvn:org.apache.felix/org.apache.felix.scr/1.8.2
{code}
            Reporter: Paolo Antinori


I have the use case described in this old discussion on Stackoverflow:

http://stackoverflow.com/questions/1566491/what-is-the-proper-way-of-disabling-an-osgi-service-at-service-start

I need my SCR annotated component to don't end up in ACTIVE state, depending on some arbitrary criteria.

I can see that throwing an Exception is not enough for the component to stay in disabled state.

And also, if I try to explicitly disable the component, I get stuck in a deadlock as per the following stacktrace:

{code}
"CM Event Dispatcher (Fire ConfigurationEvent: pid=io.fabric8.gateway.detecting)@16052" daemon prio=5 tid=0x15 nid=NA waiting
  java.lang.Thread.State: WAITING
	  at sun.misc.Unsafe.park(Unsafe.java:-1)
	  at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
	  at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
	  at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
	  at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
	  at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:236)
	  at org.apache.felix.scr.impl.manager.AbstractComponentManager.enableLatchWait(AbstractComponentManager.java:479)
	  at org.apache.felix.scr.impl.manager.AbstractComponentManager.disable(AbstractComponentManager.java:518)
	  at org.apache.felix.scr.impl.config.ConfigurableComponentHolder.disableComponents(ConfigurableComponentHolder.java:392)
	  at org.apache.felix.scr.impl.BundleComponentActivator.disableComponent(BundleComponentActivator.java:455)
	  at org.apache.felix.scr.impl.manager.ComponentContextImpl.disableComponent(ComponentContextImpl.java:175)
	  at io.fabric8.gateway.fabric.detecting.FabricDetectingGateway.modified(FabricDetectingGateway.java:227)
	  at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
	  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	  at java.lang.reflect.Method.invoke(Method.java:606)
	  at org.apache.felix.scr.impl.helper.BaseMethod.invokeMethod(BaseMethod.java:231)
	  at org.apache.felix.scr.impl.helper.BaseMethod.access$500(BaseMethod.java:39)
	  at org.apache.felix.scr.impl.helper.BaseMethod$Resolved.invoke(BaseMethod.java:624)
	  at org.apache.felix.scr.impl.helper.BaseMethod.invoke(BaseMethod.java:508)
	  at org.apache.felix.scr.impl.helper.ActivateMethod.invoke(ActivateMethod.java:149)
	  at org.apache.felix.scr.impl.manager.SingleComponentManager.invokeModifiedMethod(SingleComponentManager.java:743)
	  at org.apache.felix.scr.impl.manager.SingleComponentManager.modify(SingleComponentManager.java:698)
	  at org.apache.felix.scr.impl.manager.SingleComponentManager.reconfigure(SingleComponentManager.java:627)
	  at org.apache.felix.scr.impl.config.ConfigurableComponentHolder.configurationUpdated(ConfigurableComponentHolder.java:328)
	  at org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:290)
	  at org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2068)
	  at org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2036)
	  at org.apache.felix.cm.impl.UpdateThread.run0(UpdateThread.java:141)
	  at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:109)
	  at java.lang.Thread.run(Thread.java:745)
{code}

My invoking code is just:

{code}
    @Modified
    void modified(ComponentContext componentContext, Map<String, ?> configuration) throws Exception {
        deactivate();
        LOG.info("Re-initializing FabricDetectingGateway");
        try {
            initialize(componentContext, configuration);
        } catch (Exception e) {
            componentContext.disableComponent(COMPONENT_NAME);
        }
    }
{code}

Am I trying to perform an illegal operation, like invoking an API call from within a context where I'm not supposed to or is this a proper bug? 




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)