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

[Jonathan Halterman]

Hey Steve,


On Wed, Oct 23, 2013 at 3:24 AM, Steve Powell <steve at rabbitmq.com> wrote:

> Jonathan,
> There are some subtleties here. Comments in-line:
>
> On 22 Oct 2013, at 17:07, Jonathan Halterman <jhalterman at gmail.com> wrote:
>
> if you're doing rapid basicPublish calls to a non-existent exchange.
> Eventually basicPublish fails with an AlreadyClosedException, but this
> often occurs before the Channel's ShutdownListener is called. So the client
> has no fair way of avoiding the AlreadyClosedException.
>
> Let's get one thing out of the way first of all.
>
> Basic.Publish is an asynchronous call. Therefore, if the channel is known
> and open as far as the client is concerned, there is no good reason for the
> Basic.Publish to fail (or know anything about the exchange's existence)
> and no way for the client to prevent subsequent Basic.Publish calls until
> there are replies back from the server.  Nor is there any way to stop
> previously queued consumer actions on that channel from running. Consumers
> will be driven (eventually) with a handleShutdownSignal() as their last
> action. Any channel ShutdownListener will also be driven with the
> ShutdownSignalException passed to it, but asynchronously. Ordering of
> action and listener call is not enforced by the client.
>
> If a subsequent action on a closed channel is executed, you will get an
> AlreadyClosedException (sometimes—ought this to be always?) and this is
> due to an application initiated action (!), and has a channel reference.
>  (It is represented as a hard error, which is probably wrong.)
>
> Given the channel reference you can get the ShutdownSignalException *which
> closed that channel* with Channel.getCloseReason().
> This also works on Connections.
>

Ah yes, thanks for this pointer.


>
> So from my perspective, there are a few things I'd prefer to see out of
> all this:
>
> - That AlreadyClosedExceptions be allowed to represent channels that were
> already closed (as seems to be the case with the reference being set to a
> Channel).
>
> On Channel method calls it does that already, but has hardError set to
> true, which is sometimes misleading.
>
> - That an invocation against a Channel that has already been closed does
> not result in the Connection being closed (as seems to be the case).
>
> It depends on what you mean by 'already closed'. If the client knows it
> has closed, then yes, I agree with you. If it doesn't (yet) know it has
> closed (as in the case for a little while after a publish to a non-existent
> exchange) then it may not be able to throw an exception (yet).  It may,
> though, because some actions are synchronous with server interaction, which
> means we can tell from the response if something went wrong.
>

In the case of basicPublish to a non-existent queue, eventually the channel
will be closed, but the first time the client learns that the channel has
been closed might be when it receives an AlreadyClosedException. And that's
fine to me, as long as it doesn't result in the connection being closed,
which it doesn't right now.


>
> - That AlreadyClosedExceptions include the Method that originally cased
> the closure as the shutdown reason (if any), such as 404. This would allow
> me to determine why a basicPublish fails.
>
> See above: given the object that has closed, you should be able to get the
> ShutdownSignalException and determine why it closed.
>
> Steve Powell  [*Cell*: +44-7815-838-558] [RabbitMQ<http://www.rabbitmq.com/>
> ,* *Pivotal <http://gopivotal.com/>]
> *“L’enfer, c’est les autres.” *Sartre
>
>
> _______________________________________________
> 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/20131023/db773719/attachment.htm>