TcpTransport as a daemon

[Mathos Marcer <ma...@gmail.com>]

I've been struggling with trying to determine why I couldn't get an
application to exit unless I specifically used a System.exit or killed the
process out right.  While it looks like many of the threaded parts of
activemq have been made to be daemon threads, TcpTransport (i.e.
org.apache.activemq.transport.tcp.TcpTransport) still contains a case where
it explicitly sets it as a non-daemon thread (i.e. setDaemon(false)).  The
case is on line 142, this corresponds to instantiation of TcpTransport with
the following parameters: WireFormat wireFormat, SocketFactory
socketFactory, URI remoteLocation, URI localLocation.  I changed this value
and recompiled and it allows me to close properly.  Is there a reason one
should not do have TcpTransport as a daemon in this instance?  Is this a
patch that could/should be added?


[1] If I explicitly issued a close on the connection, it would have exited;
however, this is part of a log handler I am writing which waits for all
non-daemon threads to finish before issuing a close which in my case closes
the connection.


==
tc
-- 
View this message in context: http://www.nabble.com/TcpTransport-as-a-daemon-tp19505043p19505043.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.

Re: TcpTransport as a daemon

[James Strachan <ja...@gmail.com>]

2008/9/16 Mathos Marcer <ma...@gmail.com>:
>
> I've been struggling with trying to determine why I couldn't get an
> application to exit unless I specifically used a System.exit or killed the
> process out right.  While it looks like many of the threaded parts of
> activemq have been made to be daemon threads, TcpTransport (i.e.
> org.apache.activemq.transport.tcp.TcpTransport) still contains a case where
> it explicitly sets it as a non-daemon thread (i.e. setDaemon(false)).  The
> case is on line 142, this corresponds to instantiation of TcpTransport with
> the following parameters: WireFormat wireFormat, SocketFactory
> socketFactory, URI remoteLocation, URI localLocation.  I changed this value
> and recompiled and it allows me to close properly.  Is there a reason one
> should not do have TcpTransport as a daemon in this instance?  Is this a
> patch that could/should be added?
>
>
> [1] If I explicitly issued a close on the connection, it would have exited;
> however, this is part of a log handler I am writing which waits for all
> non-daemon threads to finish before issuing a close which in my case closes
> the connection.

How about configuring the TCP transport for your logging JMS
connection to not use daemon threads? Most other JMS clients shouldn't
use daemon threads though i'd have thought; any application which
subscribes to JMS queues/topics you'd expect to keep running until you
closed the connection.

e.g. try using this broker URL to connect to ActiveMQ

tcp://localhost:61616?daemon=true

Let us know if that works
-- 
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://open.iona.com