Robert Varga created FELIX-6315:
-----------------------------------
Summary: Factory components are eagerly deactivated
Key: FELIX-6315
URL: https://issues.apache.org/jira/browse/FELIX-6315
Project: Felix
Issue Type: Bug
Components: Declarative Services (SCR)
Affects Versions: scr-2.1.20
Reporter: Robert Varga
When a factory component with a services is is created via a call to
ComponentFactory.newInstance(), it is treated as a delayed component where
service reference counting is concerned. Specifically, if the resulting service
undergoes a getService()/ungetService(), the component configuration is
deactivated because the reference count reaches zero:
{noformat}
2020-07-31T17:48:18,135 | INFO | Blueprint Extender: 3 |
AbstractAdaptedService | 145 -
org.opendaylight.mdsal.binding-dom-adapter - 6.0.5.SNAPSHOT | Binding/DOM
adapter for DataBroker deactivated (0)
java.lang.Throwable: null
at
org.opendaylight.mdsal.binding.dom.adapter.osgi.AbstractAdaptedService.stop(AbstractAdaptedService.java:40)
[bundleFile:?]
at
org.opendaylight.mdsal.binding.dom.adapter.osgi.OSGiDataBroker.deactivate(OSGiDataBroker.java:76)
[bundleFile:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
~[?:?]
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
~[?:?]
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
~[?:?]
at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
at
org.apache.felix.scr.impl.inject.methods.BaseMethod.invokeMethod(BaseMethod.java:242)
[bundleFile:?]
at
org.apache.felix.scr.impl.inject.methods.BaseMethod.access$500(BaseMethod.java:41)
[bundleFile:?]
at
org.apache.felix.scr.impl.inject.methods.BaseMethod$Resolved.invoke(BaseMethod.java:678)
[bundleFile:?]
at
org.apache.felix.scr.impl.inject.methods.BaseMethod.invoke(BaseMethod.java:524)
[bundleFile:?]
at
org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:318)
[bundleFile:?]
at
org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:308)
[bundleFile:?]
at
org.apache.felix.scr.impl.manager.SingleComponentManager.disposeImplementationObject(SingleComponentManager.java:409)
[bundleFile:?]
at
org.apache.felix.scr.impl.manager.SingleComponentManager.deleteComponent(SingleComponentManager.java:164)
[bundleFile:?]
at
org.apache.felix.scr.impl.manager.SingleComponentManager.ungetService(SingleComponentManager.java:1022)
[bundleFile:?]
at
org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse$2.run(ServiceFactoryUse.java:260)
[org.eclipse.osgi-3.12.100.jar:?]
at
org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse$2.run(ServiceFactoryUse.java:1)
[org.eclipse.osgi-3.12.100.jar:?]
at java.security.AccessController.doPrivileged(Native Method) [?:?]
at
org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse.factoryUngetService(ServiceFactoryUse.java:258)
[org.eclipse.osgi-3.12.100.jar:?]
at
org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse.ungetService(ServiceFactoryUse.java:160)
[org.eclipse.osgi-3.12.100.jar:?]
at
org.eclipse.osgi.internal.serviceregistry.ServiceConsumer$2.ungetService(ServiceConsumer.java:50)
[org.eclipse.osgi-3.12.100.jar:?]
at
org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.ungetService(ServiceRegistrationImpl.java:593)
[org.eclipse.osgi-3.12.100.jar:?]
at
org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.ungetService(ServiceRegistry.java:540)
[org.eclipse.osgi-3.12.100.jar:?]
at
org.eclipse.osgi.internal.framework.BundleContextImpl.ungetService(BundleContextImpl.java:666)
[org.eclipse.osgi-3.12.100.jar:?]
at
org.opendaylight.controller.blueprint.ext.StaticServiceReferenceRecipe.doStop(StaticServiceReferenceRecipe.java:90)
[bundleFile:?]
at
org.apache.aries.blueprint.container.AbstractServiceReferenceRecipe.stop(AbstractServiceReferenceRecipe.java:156)
[bundleFile:1.10.2]
at
org.opendaylight.controller.blueprint.ext.AbstractDependentComponentFactoryMetadata.stopServiceRecipes(AbstractDependentComponentFactoryMetadata.java:211)
[bundleFile:?]
at
org.opendaylight.controller.blueprint.ext.AbstractDependentComponentFactoryMetadata.stopTracking(AbstractDependentComponentFactoryMetadata.java:197)
[bundleFile:?]
at
org.opendaylight.controller.blueprint.ext.DataStoreAppConfigMetadata.stopTracking(DataStoreAppConfigMetadata.java:55)
[bundleFile:?]
at
org.apache.aries.blueprint.di.DependentComponentFactoryRecipe.stop(DependentComponentFactoryRecipe.java:67)
[bundleFile:1.10.2]
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.untrackServiceReference(BlueprintContainerImpl.java:673)
[bundleFile:1.10.2]
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.untrackServiceReferences(BlueprintContainerImpl.java:653)
[bundleFile:1.10.2]
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.processProcessors(BlueprintContainerImpl.java:582)
[bundleFile:1.10.2]
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:417)
[bundleFile:1.10.2]
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:298)
[bundleFile:1.10.2]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
at
org.apache.aries.blueprint.container.ExecutorServiceWrapper.run(ExecutorServiceWrapper.java:106)
[bundleFile:1.10.2]
at
org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:45)
[bundleFile:1.10.2]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
[?:?]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
[?:?]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
[?:?]
at java.lang.Thread.run(Thread.java:834) [?:?]
{noformat}
(Sorry for the non-minimal stack trace).
This seems to run contrary to *Figure 112.4* in R7 spec, which lists only two
causes for deactivation:
* when the configuration is explicitly disposed
* when the configuration becomes unsatisified
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
