You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Tobias Gunkel (JIRA)" <ji...@apache.org> on 2019/07/24 13:19:00 UTC
[jira] [Updated] (FELIX-6162) ConfigurationManager crashes on
shutdown if PersistenceManager not yet available
[ https://issues.apache.org/jira/browse/FELIX-6162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tobias Gunkel updated FELIX-6162:
---------------------------------
Description:
If ConfigurationManager shuts down, it tries to close the managedServiceFactoryTracker and managedServiceTracker.
ConfigurationManager.stop():
{code:java}
// stop handling ManagedService[Factory] services
managedServiceFactoryTracker.close();
managedServiceTracker.close();
{code}
In integration tests both services might not available at this time and it crashes:
{code:java}
java.lang.NullPointerException
at org.apache.felix.cm.impl.ConfigurationManager.stop(ConfigurationManager.java:222)
at org.apache.felix.cm.impl.ConfigurationAdminStarter.deactivate(ConfigurationAdminStarter.java:95)
at org.apache.felix.cm.impl.DependencyTracker.stop(DependencyTracker.java:112)
at org.apache.felix.cm.impl.Activator.stop(Activator.java:160)
at org.apache.felix.framework.util.SecureAction.stopActivator(SecureAction.java:720)
at org.apache.felix.framework.Felix.stopBundle(Felix.java:2795)
{code}
++
{code:java}
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1557)
at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
at java.lang.Thread.run(Thread.java:748)
{code}
The reason for this is that managedServiceTracker and managedServiceFactoryTracker are assigned *after* service registration of ConfigurationAdmin in the start() method.
The integration test is (sometimes) directly run after the bundleContext.registerService(ConfigurationAdmin.class, ...) line. And directly after the integration test execution the Configuration.stop() method is called where it crashes as managedServiceTracker and managedServiceFactoryTracker are still null.
ConfigurationManager.start():
{code:java}
configurationAdminRegistration = bundleContext.registerService(ConfigurationAdmin.class, caf,
serviceProperties);
// start handling ManagedService[Factory] services
managedServiceTracker = new ManagedServiceTracker(this);
managedServiceFactoryTracker = new ManagedServiceFactoryTracker(this);
{code}
Although this sounds like a rare race-condition, it is reproducible in our test environment. About 30% of the tests fail with the above exception.
A simple solution would be to just add null-checks (as with every other service that is accessed in the stop() method):
ConfigurationManager.stop():
{code:java}
// stop handling ManagedService[Factory] services
if (managedServiceFactoryTracker != null)
{
managedServiceFactoryTracker.close();
}
if (managedServiceTracker != null)
{
managedServiceTracker.close();
}
{code}
was:
If ConfigurationManager shuts down, it tries to close the managedServiceFactoryTracker and managedServiceTracker.
ConfigurationManager.stop():
{code}
// stop handling ManagedService[Factory] services
managedServiceFactoryTracker.close();
managedServiceTracker.close();
{code}
In integration tests this might not be the case and it crashes:
{code}
java.lang.NullPointerException
at org.apache.felix.cm.impl.ConfigurationManager.stop(ConfigurationManager.java:222)
at org.apache.felix.cm.impl.ConfigurationAdminStarter.deactivate(ConfigurationAdminStarter.java:95)
at org.apache.felix.cm.impl.DependencyTracker.stop(DependencyTracker.java:112)
at org.apache.felix.cm.impl.Activator.stop(Activator.java:160)
at org.apache.felix.framework.util.SecureAction.stopActivator(SecureAction.java:720)
at org.apache.felix.framework.Felix.stopBundle(Felix.java:2795)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1557)
at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
at java.lang.Thread.run(Thread.java:748)
{code}
The reason for this is that managedServiceTracker and managedServiceFactoryTracker are assigned after service registration of ConfigurationAdmin.
The unit test is (sometimes) directly run after the bundleContext.registerService(ConfigurationAdmin.class, ...) line. And directly after the integration test execution the Comfiguration.stop() method is called where it crashes as managedServiceTracker and managedServiceFactoryTracker are still null.
ConfigurationManager.start():
{code}
configurationAdminRegistration = bundleContext.registerService(ConfigurationAdmin.class, caf,
serviceProperties);
// start handling ManagedService[Factory] services
managedServiceTracker = new ManagedServiceTracker(this);
managedServiceFactoryTracker = new ManagedServiceFactoryTracker(this);
{code}
Although this sounds like a rare race-condition, it is reproducible in our test environment. About 30% of the tests fail with the above exception.
A simple solution would be to just add null-checks (as with every other service that is accessed in the stop() method):
ConfigurationManager.stop():
{code}
// stop handling ManagedService[Factory] services
if (managedServiceFactoryTracker != null)
{
managedServiceFactoryTracker.close();
}
if (managedServiceTracker != null)
{
managedServiceTracker.close();
}
{code}
> ConfigurationManager crashes on shutdown if PersistenceManager not yet available
> --------------------------------------------------------------------------------
>
> Key: FELIX-6162
> URL: https://issues.apache.org/jira/browse/FELIX-6162
> Project: Felix
> Issue Type: Bug
> Components: Configuration Admin
> Reporter: Tobias Gunkel
> Priority: Major
>
> If ConfigurationManager shuts down, it tries to close the managedServiceFactoryTracker and managedServiceTracker.
> ConfigurationManager.stop():
> {code:java}
> // stop handling ManagedService[Factory] services
> managedServiceFactoryTracker.close();
> managedServiceTracker.close();
> {code}
> In integration tests both services might not available at this time and it crashes:
> {code:java}
> java.lang.NullPointerException
> at org.apache.felix.cm.impl.ConfigurationManager.stop(ConfigurationManager.java:222)
> at org.apache.felix.cm.impl.ConfigurationAdminStarter.deactivate(ConfigurationAdminStarter.java:95)
> at org.apache.felix.cm.impl.DependencyTracker.stop(DependencyTracker.java:112)
> at org.apache.felix.cm.impl.Activator.stop(Activator.java:160)
> at org.apache.felix.framework.util.SecureAction.stopActivator(SecureAction.java:720)
> at org.apache.felix.framework.Felix.stopBundle(Felix.java:2795)
> {code}
> ++
> {code:java}
> at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1557)
> at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> The reason for this is that managedServiceTracker and managedServiceFactoryTracker are assigned *after* service registration of ConfigurationAdmin in the start() method.
> The integration test is (sometimes) directly run after the bundleContext.registerService(ConfigurationAdmin.class, ...) line. And directly after the integration test execution the Configuration.stop() method is called where it crashes as managedServiceTracker and managedServiceFactoryTracker are still null.
> ConfigurationManager.start():
> {code:java}
> configurationAdminRegistration = bundleContext.registerService(ConfigurationAdmin.class, caf,
> serviceProperties);
> // start handling ManagedService[Factory] services
> managedServiceTracker = new ManagedServiceTracker(this);
> managedServiceFactoryTracker = new ManagedServiceFactoryTracker(this);
> {code}
> Although this sounds like a rare race-condition, it is reproducible in our test environment. About 30% of the tests fail with the above exception.
> A simple solution would be to just add null-checks (as with every other service that is accessed in the stop() method):
> ConfigurationManager.stop():
> {code:java}
> // stop handling ManagedService[Factory] services
> if (managedServiceFactoryTracker != null)
> {
> managedServiceFactoryTracker.close();
> }
> if (managedServiceTracker != null)
> {
> managedServiceTracker.close();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)