[
https://issues.apache.org/jira/browse/FELIX-2434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13031263#comment-13031263
]
Emmanuel Lecharny commented on FELIX-2434:
------------------------------------------
It's a bit more complex than that :)
We don't requires our users to call felix.start(). In fact, our API is either
loaded by an OSGi capable application, and we don't start felix at all, or we
detect that the user does not use a OSGi container, and in this case, when he
opens the very first connection to a LDAP server, we then start felix (but the
user does not know about it). We do that only once, as a user may create as
many connection as he wants.
Now, when the user is done with his connections, he can close them, but that
does not stop felix (who knows, he might create a new connection again, send a
new LDAP requests later).
So here we are : we have to ask the user to call some strange method to stop
something the user does not even know is started, when he is done with his
program.
Here is an example of what a user can do :
public static void main(String[] args) throws Exception
{
LdapNetworkConnection lc = new LdapNetworkConnection();
lc.bind();
lc.add( <an entry> );
lc.close();
System.out.println( "So long, folks..." );
}
but he gets stuck for ever here.
This is why we would like to be able to modify the Dispatcher thread
programatically through a Felix option to make it a daemon thread.
And trust me, here, we *know* what we are doing :)
> DispatchQueue, StartLevel and PacakageAdmin threads holding VM up.
> ------------------------------------------------------------------
>
> Key: FELIX-2434
> URL: https://issues.apache.org/jira/browse/FELIX-2434
> Project: Felix
> Issue Type: Bug
> Components: Framework
> Affects Versions: framework-2.0.5
> Environment: Linux (RHEL 4 32Bit), java 1.6 server vm (14-b08)
> Linux (RHEL 5 32bit & 64Bit) java 1.6 server vm (13)
> Reporter: Martin Ritchie
> Fix For: framework-4.0.0
>
> Attachments: FELIX-EventDispatcher-setDaemon.patch
>
>
> Hi, In Qpid we started using Felix more for managing our broker plugins.
> However we are having random lockups occur during our test broker shutdown.
> Our PluginManager
> (https://svn.apache.org/repos/asf/qpid/trunk/qpid/java/broker/src/main/java/org/apache/qpid/server/plugins/PluginManager.java)
> is shutdown via a VM ShutdownHook where it closes Service Trackers and then
> calls stop() on Felix followed by a waitForStop().
> We are frequently seeing the following three Felix threads in a WAITING state
> that could be holding the VM up. Looking at the 2.0.5 code the
> EventDispatcher does not use a Daemon thread could this be what is holding
> our VM open?
> Name: FelixDispatchQueue
> State: WAITING on java.util.ArrayList@dc904a
> Total blocked: 21 Total waited: 22
> Stack trace:
> java.lang.Object.wait(Native Method)
> java.lang.Object.wait(Object.java:485)
> org.apache.felix.framework.util.EventDispatcher.run(EventDispatcher.java:917)
> org.apache.felix.framework.util.EventDispatcher.access$000(EventDispatcher.java:54)
> org.apache.felix.framework.util.EventDispatcher$1.run(EventDispatcher.java:106)
> java.lang.Thread.run(Thread.java:619)
> Name: FelixStartLevel
> State: WAITING on java.util.ArrayList@1c68b20
> Total blocked: 7 Total waited: 8
> Stack trace:
> java.lang.Object.wait(Native Method)
> java.lang.Object.wait(Object.java:485)
> org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:242)
> java.lang.Thread.run(Thread.java:619)
> Name: FelixPackageAdmin
> State: WAITING on org.apache.felix.framework.PackageAdminImpl@1d4ab05
> Total blocked: 0 Total waited: 1
> Stack trace:
> java.lang.Object.wait(Native Method)
> java.lang.Object.wait(Object.java:485)
> org.apache.felix.framework.PackageAdminImpl.run(PackageAdminImpl.java:316)
> java.lang.Thread.run(Thread.java:619)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
