[rabbitmq-discuss] JAVA client / non daemon threads / shutdown hook

[Steve Powell]

Bartłomiej,

What a very good point. It is clear that the MainLoop thread ought to be
a daemon thread in your circumstances, thank you for pointing this out.
The only affect of this will be to allow the JVM to terminate if only
daemon threads are available.

However, we have considered this problem before (internal bug 21110) and
user apps that create a connection and register some consumers (which do
all the work) ought to be able to terminate without accidentally killing
the connection processing.

This means that there are circumstances in which the threads we create
are required to be non-daemon, and circumstances where you would like
them to be daemon.

The hook you implemented ought to work correctly even when the MainLoop
is not a daemon, because closing the connection ought to make the
MainLoop thread terminate normally. If it doesn't, there is a bug. Where
at all possible you should attempt to close an open connection as a part
of your termination processing as there are system resources that could
be left high-and-dry if you do not.

There are other threads in the Java Client -- the executor worker
threads used for Consumer callbacks. These are non-daemon, too. The hook
should still work because shutting down the connection ought to shutdown
the consumer work service, and in turn the executor (and its worker
threads).

However, I could make them daemon threads as well, in case the main app
terminates abruptly and expects to be able to terminate uncleanly as you
describe.

Thank you for reporting this. I'll report back here on progress.

Steve Powell  (a happy bunny)
----------yet more definitions from the SPD----------
corrugate (n.) T.V. soap scandal.
olympic (n.) A camp road-digger.
jamboree (n.) A conserve made from French cheese.

On 18 May 2012, at 16:27, Bartłomiej Prokop wrote:

> Hi,
> 
> I'm using JAVA client for RabbitMQ (com.rabbitmq:amqp-client:2.8.1) to write a "jar component" capable of sending messages for some legacy system. The idea is to wrap all code that maintain the connection inside my component. This way, the client software deals only with very simple methods like "post" and is not aware of any connection handling. The connect/reconnect code is written and hidden from the legacy system.
> 
> The problem I have faced is that Java client creates "behind the scene" some threads to manage connection - like:
>          lines 299-301 of AMQConnection class.
>         // start the main loop going
>         new MainLoop("AMQP Connection " + getHostAddress() + ":" + getPort()).start();
>         // after this point clear-up of MainLoop is triggered by closing the frameHandler.
> 
> Unfortunatelly, those threads aren't "daemon" threads. So, when main application ends and appropriate connection closing not occurs, the VM won't terminate. My approach was to add some shutdown hook to close RabbitMQ connections if it is live inside my "jar component". But, due to those non-daemon threads, VM is not going ever to be terminated and shutdown hooks fired.
> 
> It is a question to RabbitMQ driver developers, if the internal threads could be fired as daemon threads, could it be done in future releases?
> 
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss