activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <>
Subject Re: TcpTransport as a daemon
Date Tue, 16 Sep 2008 08:27:40 GMT
2008/9/16 Mathos Marcer <>:
> 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


Let us know if that works

Open Source Integration

View raw message