[rabbitmq-discuss] Telling clean shutdown from an error-related one

Thu May 16 09:14:46 BST 2013

Hi Michael,

On 15 May 2013, at 21:51, Michael Klishin wrote:

> I'm investigating an issue report for Langohr:
> https://github.com/michaelklishin/langohr/issues/16#issuecomment-17964559
> 
> and not entirely sure when SignalShutdownException#isInitiatedByApplication
> returns true and if it can really be used to tell a clean shutdown (e.g. when you
> voluntarily close channels).
> 

That property will evaluate to true whenever the source of the shutdown originated in the client application, whether by deliberate closure or application error. So I'm not sure that you can differentiate based on that properly alone. Certainly the property will always be set to true when a channel is deliberately closed by the application, via a call to #close() or #waitForConfirmsOrDie and so on. However the comment at https://github.com/michaelklishin/langohr/issues/16#issuecomment-17964103 is correct, in that an exception in the consumer code will still set #isInitiatedByApplication to true.

So IMO, even when #isInitiatedByApplication is true, we should probably make it easier to determine whether a channel close was a deliberate action or the result of an application error. I'll file a bug for that.

> What's the recommended way to detect network errors

For these, #isInitiatedByApplication will be false. You can also look at the exception tucked away in #getReason to determine this, at least to some extent.

> , channel AND consumer-level exceptions vs clean termination?

There is no clean way to do this atm afaict - I think Ian Eure's analysis is correct and the the only way to differentiate between the two right now would be to "go spelunking through the object tree looking for the text 'Closed due to exception'" in Exception#getMessage. As I said, we'll fix that.

Cheers,
Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20130516/1be834b2/attachment.htm>