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

[Steve Powell]

On 22 Oct 2013, at 11:42, Steve Powell <steve at rabbitmq.com> wrote:

> Issuing a 'real work' call after closing the channel, like channel.basicConsume(), throws an AlreadyClosedException, claiming that the connection is closed, but conn.isOpen() still returns true.

Well, it appears that the AlreadyClosedException produces the "clean connection shutdown" string when it is a hard error (which is correct). It is called by the (internal) 'channel.ensureIsOpen()' method (typically, if we are about to communicate across the channel).  But the reference in the exception is then to a Channel, and although the exception implies that the connection has been closed, it hasn't.  This appears to contradict the hard error flag: which is supposed to mean the connection is closed.

I guess this means that the bug is the connection isn't closed by the application initiated call to a closed channel.  

You could argue this particular channel error doesn't violate the protocol, so there is no reason to suppose that the connection would (or should) be closed, so it shouldn't be a hard error.  [The code comments imply that hardError==true implies that getReference() returns a Connection object, which is actually not true anyway.]

As this thread stated right at the beginning (see subject), there is no provision in the code for issuing an AlreadyClosedException without it being a hard error.  If we could do this, the meaning of hardError would be preserved.

As in the case of referring to a consumer that the client has no record of, the client code can often determine if the channel is already closed, and not risk any protocol violations before throwing the exception.  In these cases, it ought not to be a hard error: the connection can remain unaffected.

Steve Powell  [Cell: +44-7815-838-558] [RabbitMQ, Pivotal]
“L’enfer, c’est les autres.” Sartre
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20131022/403d6f31/attachment.htm>