[rabbitmq-discuss] AlreadyClosedException always sets hardError and initiatedByApplication to true

[Steve Powell]

Jonathan,

I think it is not a bug but working as designed:

The second invocation on the channel is an invocation on a closed channel, and this is a hard error, because it closes the connection. Furthermore this was initiated by an application call rather than arriving out of the blue from the server.

There is no reason to expect that the 'flags' on the AlreadyClosedException have anything to do with the event which closed the channel/connection.

As to the problem about recovery, it is the first exception (the IOException) which you need to catch; its cause will be the ShutdownSignalException, which tells you what the circumstances of the shutdown are (application?, hard?).

Is this enough to help you recover correctly?

Steve Powell  [Cell: +44-7815-838-558]
Links: Pivotal, SpringSource, VMware, Virgo, RabbitMQ.
-----------------------------------------------------------------------
Good design:
   is innovative, useful, and aesthetic;
   is understandable, unobtrusive, and honest;
   is long-lasting, thorough, and environmentally friendly;
   and is as little design as possible.
(c) Dieter Rams, amended 2003; 2009; 2012

On 15 Oct 2013, at 23:56, Jonathan Halterman <jhalterman at gmail.com> wrote:

> Hey Michael,
> 
> Yea, you can reproduce both items by attempting to declare a consumer on a non-existent queue twice in a row. The first invocation closes the channel and throws an IOException. The second invocation throws an AlreadyClosedException, though the hardError and initiatedByApplication flags don't match those from the initial failure.
> 
> - jonathan
> 
> 
> On Tue, Oct 15, 2013 at 3:45 PM, Michael Klishin <mklishin at gopivotal.com> wrote:
> On oct 16, 2013, at 1:24 a.m., Jonathan Halterman <jhalterman at gmail.com> wrote:
> 
> > I noticed that AlreadyClosedException always sets hardError and initiatedByApplication to true, even if the error was not hard (only the channel was closed) and the channel was not closed by the application. This makes it more difficult to properly recover a closed resource if I can't easily determine which resource was closed and why. Could this be fixed?
> 
> Jonathan,
> 
> This indeed sounds like a bug.
> 
> How can we reproduce it? Simply attempt an operation on a closed channel?
> Does it matter how exactly the channel was closed?
> 
> MK
> 
> 
> 
> 
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20131016/493d6a90/attachment.htm>