You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Carsten Ziegeler (JIRA)" <ji...@apache.org> on 2017/04/10 14:28:41 UTC
[jira] [Commented] (FELIX-5612) [SCR] Deadlock while invoking SCR
api from lifecycle methods
[ https://issues.apache.org/jira/browse/FELIX-5612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15962953#comment-15962953 ]
Carsten Ziegeler commented on FELIX-5612:
-----------------------------------------
It seems you're using an old version of SCR (1.8.2), I suggest trying the latest 2.0.8
> [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)
> Affects Versions: scr-1.8.2
> 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)