[
https://issues.apache.org/jira/browse/FELIX-2434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13031412#comment-13031412
]
Emmanuel Lecharny commented on FELIX-2434:
------------------------------------------
I understand that killing the container brutally might corrupt some data, and
defaulting to such a behavior is certainly a bad idea. But if it's optionnal,
and if you select this option, then you are on your own, and you can only blame
yourself if something get lost. Morever, we can deal with such a problem by
adding a shutdownHook that closes Felix properly. It works fine when I just
call a System.exit(0).
Regardig our usage, short answer is no, we don't have any idea if there is any
remainig connection. The users might perfectly well have let some connection
opened, but that does not matter too much (actually, I was thinking about using
a counter to warn the user if any connection remains opened). Worse, some
connections might be opened and never closed on purpose, for instance when
doing a persistent search ( serach that last forever, and receives any
modification done on the server. Quite convenient).
In a more general case, a user will open a connection, do something on the LDAP
server, eventually close the connection, do something else (not related to the
LDAP server), then open a connection again, etc. We simply can't know what the
user will do in fact, so we can't stop Felix when no connection is opened.
It would be easier for us if we had a way to initialize the system, forcing us
to clean it up at the end, but we don't initialize anything before the first
connection is opened. The idea was to keep it as simple as possible for the
guys who have to do some LDAP.
Being able to get the container been shut down when we exit the main() method
would simply save us an extra method call on the user side. There is no
performance penalty, closig Felix is just a breeze.
Again, I see how dangerous it can be to have this as a default behavior, but if
we can set a FelixConstant property which sets the thread.setDaemon( true )
could help in our case.
Anyway, there is no urgency, let's churn it as you said, maybe we can find a
better way to mitigate with this small annoyance for us.
> 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
