Hi, I'm trying to figure out what values the ShutdownEventArgs.ReplyCode
property can be assigned by the .NET client.
I started investigating while trying to solve a reconnection problem
whereby the connection was shutdown by the AppDomain unload event handler
and exited with code 0x21d, but noticed there's at least another case in
the code where the ReplyCode is assigned the same value, and it's in the
MainLoop method, in the last chance catch block.
Using same codes for different shutdown reasons makes it difficult to
distinguish different shutdown scenarios, and I would like to avoid relying
on the ReplyText property to discriminate it.
So I'm wondering what is the criteria used by the API to set this value
and, bumping one thread from some time ago, it would be very nice to have
some guidance about how the .NET API behaves when anything goes wrong.
Currently I have to say that it's quite difficult to cope with failure
scenarios because the behavior of the API is difficult to predict, and I am
under the impression that it is somewhat inconsistent in terms of which
exceptions you have to expect to bubble up in different circumstances.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20120204/8b254831/attachment.htm>

Search Discussions

  • Emile Joubert at Feb 6, 2012 at 10:27 am
    Hi Simone,
    On 03/02/12 23:54, Simone Busoli wrote:
    Hi, I'm trying to figure out what values the ShutdownEventArgs.ReplyCode
    property can be assigned by the .NET client.
    Thanks for your feedback. There is a relative scarcity of error codes.
    The AMQP specification only defines only a small number, which means
    that some codes have to be re-used. "Precondition failed" (406) is a
    good example of a code that is widely used, so the code alone does not
    identify a unique problem.

    The code in your example is "Internal error" (541). This code should be
    read as an error class and you need to inspect the error message for
    more detail.


    -Emile
  • Steven Taylor at Feb 7, 2012 at 5:10 am
    If you wanted to, the RabbitMQ team could subclass the AQMP error codes.
    i.e. treat the AQMP number as the category, and then have a unique cause
    numbers underneath these.

    Is there any guidance on the site / in PDF on getting subscribers to
    reconnect + reponding to these events in a fault tolerant way? I mean, I /
    we can evolve an approach, but if there was a starting point / code
    example, that would be really helpful.

    btw: recently in debugging, I appreciated that using the same DeliveryTag
    twice generated an exception, but I'm not sure that the channel should have
    automatically disconnected. Just thought I'd mention it.

    thanks,
    -Steven
    On 6 February 2012 10:27, Emile Joubert wrote:

    Hi Simone,
    On 03/02/12 23:54, Simone Busoli wrote:
    Hi, I'm trying to figure out what values the ShutdownEventArgs.ReplyCode
    property can be assigned by the .NET client.
    Thanks for your feedback. There is a relative scarcity of error codes.
    The AMQP specification only defines only a small number, which means
    that some codes have to be re-used. "Precondition failed" (406) is a
    good example of a code that is widely used, so the code alone does not
    identify a unique problem.

    The code in your example is "Internal error" (541). This code should be
    read as an error class and you need to inspect the error message for
    more detail.


    -Emile
    _______________________________________________
    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/20120207/8582571d/attachment.htm>
  • Emile Joubert at Feb 7, 2012 at 12:26 pm
    Hi Steven,
    On 07/02/12 05:10, Steven Taylor wrote:
    btw: recently in debugging, I appreciated that using the same
    DeliveryTag twice generated an exception, but I'm not sure that the
    channel should have automatically disconnected. Just thought I'd mention it.
    Using an invalid delivery tag will lead to a channel exception, so what
    you describe is expected behaviour.


    -Emile

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouprabbitmq-discuss @
categoriesrabbitmq
postedFeb 3, '12 at 11:54p
activeFeb 7, '12 at 12:26p
posts4
users3
websiterabbitmq.com
irc#rabbitmq

People

Translate

site design / logo © 2022 Grokbase