felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FELIX-3761) When a bundle registers a service, the bundle lock is obtained without any real purpose
Date Fri, 30 Nov 2012 04:21:58 GMT

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

Richard S. Hall commented on FELIX-3761:
----------------------------------------

Perhaps I'm missing something, but if we remove the bundle lock, then isn't it possible that
the bundle could stop before the service is registered and thus the service would get missed
when unregistering all services when the bundle is stopped? Ultimately, this would leave the
service in the service registry even though the bundle is stopped.
                
> When a bundle registers a service, the bundle lock is obtained without any real purpose
> ---------------------------------------------------------------------------------------
>
>                 Key: FELIX-3761
>                 URL: https://issues.apache.org/jira/browse/FELIX-3761
>             Project: Felix
>          Issue Type: Bug
>    Affects Versions: framework-4.0.2
>            Reporter: Guillaume Nodet
>
> It leads to the following kind of deadlocks:
> {code}
> "Felix WebConsole worker" Id=170 in WAITING on lock=[Ljava.lang.Object;@108a93d9
>     at java.lang.Object.wait(Native Method)
>     at java.lang.Object.wait(Object.java:485)
>     at org.apache.felix.framework.Felix.acquireBundleLock(Felix.java:5203)
>     at org.apache.felix.framework.Felix.registerService(Felix.java:3452)
>     at org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:346)
>     at org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:320)
>     at org.apache.felix.webconsole.internal.core.BundlesServlet.activate(BundlesServlet.java:132)
>     at org.apache.felix.webconsole.internal.servlet.PluginHolder$InternalPlugin.doGetConsolePlugin(PluginHolder.java:752)
>     at org.apache.felix.webconsole.internal.servlet.PluginHolder$Plugin.getConsolePlugin(PluginHolder.java:535)
>     at org.apache.felix.webconsole.internal.servlet.PluginHolder.getPlugin(PluginHolder.java:205)
>     at org.apache.felix.webconsole.internal.servlet.OsgiManager.initInternalPlugins(OsgiManager.java:1016)
>     at org.apache.felix.webconsole.internal.servlet.OsgiManager.doUpdateConfiguration(OsgiManager.java:981)
>     at org.apache.felix.webconsole.internal.servlet.OsgiManager$6.run(OsgiManager.java:930)
>     at org.apache.felix.webconsole.internal.servlet.Executor$Worker.run(Executor.java:67)
> "FelixFrameworkWiring" Id=168 in WAITING on lock=java.lang.Object@3d6bca49
>     at java.lang.Object.wait(Native Method)
>     at java.lang.Object.wait(Object.java:485)
>     at org.apache.felix.webconsole.internal.servlet.Executor.shutdown(Executor.java:45)
>       - locked org.apache.felix.webconsole.internal.servlet.Executor@21875b11
>     at org.apache.felix.webconsole.internal.servlet.OsgiManager.dispose(OsgiManager.java:407)
>     at org.apache.felix.webconsole.internal.KarafOsgiManagerActivator.stop(KarafOsgiManagerActivator.java:52)
>     at org.apache.felix.framework.util.SecureAction.stopActivator(SecureAction.java:667)
>     at org.apache.felix.framework.Felix.stopBundle(Felix.java:2604)
>     at org.apache.felix.framework.Felix$RefreshHelper.stop(Felix.java:4961)
>     at org.apache.felix.framework.Felix.refreshPackages(Felix.java:4203)
>     at org.apache.felix.framework.FrameworkWiringImpl.run(FrameworkWiringImpl.java:172)
>     at java.lang.Thread.run(Thread.java:680)
> {code}
> There's really no need to grab the bundle lock because the bundle is necessarily starting
/ active / stopping, else an exception would have been thrown when calling the registerService
because the BundleContext object would have been invalidated, and the registry itself is synchronized.
 

--
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