[rabbitmq-discuss] Failure during shutdown with v2.3.1

[Matthew Sackman]

Hi Lee,

On Thu, Mar 10, 2011 at 08:03:42PM -0800, Lee Kirchhoff wrote:
> I recently upgraded from RabbitMQ 1.8.1 to 2.3.1 and am running in Mac and
> Ubuntu enviroments. I have a plugin that uses the amqp_client to access a
> local queue. With 2.3.1 when shutting down I get the error below, which I
> never encountered previously. There is no load when the shutdown is
> happening.

Yeah, it's not really an error, it's just that currently the connection
closing handling in the erlang client is a little funky. Basically,
it'll go away if you ensure that you manually close the channels and
then the connections. The application shutdown stuff will not close
things down at the moment without these sorts of log entries popping
out. We have a plan to fix this, though really the issue is to do with a
combination of inflexibility Erlang's logging policies and signals being
issued by terminating processes.

In short, you can ignore entries like this - if it's giving you
something like:
** Last message in was {'$gen_cast',channels_terminated}

> I tried to determine the cause. It appears that it may be something of a
> race in that when I insert a 500 msec delay in
> amqp_channels_manger:handle_channel_down/4 I get the initial internal error
> indication, but no following error report. My plugin is listed before the
> amqp_client application when I do a 'rabbitmqctl status' so I it should be
> the first getting a chance to shutdown and close its amqp connection, i.e.,
> before the amqp_client shuts down, but I suppose applications shutdown
> asynchronously.

I believe applications should be shut down according to the inverse
dependencies in the app files. Thus your application should depend on
both rabbit and amqp_client (the erlang client is now its own
application). Thus when your application shuts down, it should have a
chance to close down all channels and connections nicely, before either
amqp_client or rabbit applications start to shutdown. This should, I
believe, avoid these log entries.

Best wishes,

Matthew