You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Gordon Sim <gs...@redhat.com> on 2010/01/21 19:29:10 UTC
exceptions in the new apis
The c++ and python messaging apis need to clearly define the exceptions
that can be thrown as well as when and where they can be thrown from.
As a start I'd like to compile a list of the important error conditions
that can occur. I'm hoping other will chip in with changes and additions
and without too much effort we can get a reasonably complete list agreed
and then decide how to design the exception hierarchy used to
communicate them.
The final stage will be determining which exceptions each method in the
api may throw. There may be some exceptions very specific to particular
methods that are more obvious when we reach that stage.
* tcp socket fails (or whatever the rdma equivalent is, assuming that is
a detectable condition)
* missed heartbeats
* authentication errors
* authorisation errors
* queue not found
* exchange not found
* other address validation errors (e.g. exchange is of different type to
that specified)
* session terminated by management
* connection terminated by management
* broker side queue limit breached
* exclusive subscriber violation
* feature not supported exception from broker (e,g, unsupported exchange
type)
* protocol violation errors (by which I mean any sort of framing error
or problem that is a result of a bug in the library or broker rather
than being an invalid command by the application)
* internal error in broker, i.e. some as yet unidentified bug,
misconfiguration or environmental problem
If you have any corrections or additions either email them back or edit
the wiki page:
http://cwiki.apache.org/confluence/display/qpid/API+Error+Conditions
--Gordon.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: exceptions in the new apis
Posted by Gordon Sim <gs...@redhat.com>.
On 01/28/2010 07:20 PM, Rajith Attapattu wrote:
> For example the application may need to distinguish between the
> following scenarios as the behaviour could be different for each case.
> Connection closed with an error code - the behaviour would depend on
> the error code.
> Host unreachable - it may try the same broker after configurable
> interval in case it was due to a temporary network failure.
> Connection refused - then it may decide to try the next know broker.
While network and broker failure are indeed different conditions - which
I think is your key point - I'm not sure it would always be possible to
accurately determine which one[1] it was and I'm still not entirely that
anyone would want to treat those differently.
[1] There is for example also the case (different from both of these)
where the network connection is established (e.g. socket is accepted)
but the broker or network fails before AMQP connection handshaking
completes.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: exceptions in the new apis
Posted by Rajith Attapattu <ra...@gmail.com>.
On Tue, Jan 26, 2010 at 7:19 AM, Gordon Sim <gs...@redhat.com> wrote:
> On 01/25/2010 02:29 PM, Alan Conway wrote:
>>
>> Should we distinguish failure to establish connection from failure of an
>> established connection? Note that if the client is doing failover the
>> distinction is somewhat blurred.
>
> I think the second point implies that if there are two separate exceptions
> to cover these different cases one would want to have a common parent (so
> for failover you can ignore the distinction).
>
> I would be tempted to just have one exception and use the error message to
> provide more detail. Is there a use-case anyone can think of where you would
> actually want to execute different logic in handling these two cases?
If failover is handled by the messaging client,
=======================================
Then If an established connection fails (network failure, connection
error or broker dying) then the application may not be interested as
long as the client could connect to another broker (within the same
cluster).
The application will if only care if all attempts to connect to known
brokers have failed. In such a case the *application* may connect to a
secondary backup site or initiate some other logic.
For this use case the application would only care about a "failure to
establish connection". If this happens then there is either a network
issue where the entire cluster is unreachable, or a total cluster
failure where all nodes have gone kaput.
However for debug and operational reasons the actual error that caused
each individual connection failure should be notified via a "warn"
message in the logs.
Perhaps the "failure to establish connection" Exception could carry a
list of last x connection errors which could help the application to
generate alarms etc.. rather than log scraping.
Also if a connection attempt fails due an authentication or
authorization error, the application may need to know sooner than
later. In such a case the failover logic should not be initiated and
the correct exception should be thrown.
If failover is handled by the application,
=================================
Then if an established connection (or an attempt to connect) fails
(network failure, connection error or broker dying) then the
application will need to know what exactly happened, so it could
initiate the necessary steps.
For example the application may need to distinguish between the
following scenarios as the behaviour could be different for each case.
Connection closed with an error code - the behaviour would depend on
the error code.
Host unreachable - it may try the same broker after configurable
interval in case it was due to a temporary network failure.
Connection refused - then it may decide to try the next know broker.
I think we have already seen both use cases in production
environments. So I do believe both types of exceptions needs to be
present and thrown appropriately from the messaging client.
Their intent should be clearly documented so the client would know
which one to use.
Rajith
> In any case I've added both conditions as distinct items to the list of
> error conditions, along with the others you suggested (still chewing over
> the transaction related errors). Thanks!
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: exceptions in the new apis
Posted by Gordon Sim <gs...@redhat.com>.
On 01/25/2010 02:29 PM, Alan Conway wrote:
> Should we distinguish failure to establish connection from failure of an
> established connection? Note that if the client is doing failover the
> distinction is somewhat blurred.
I think the second point implies that if there are two separate
exceptions to cover these different cases one would want to have a
common parent (so for failover you can ignore the distinction).
I would be tempted to just have one exception and use the error message
to provide more detail. Is there a use-case anyone can think of where
you would actually want to execute different logic in handling these two
cases?
In any case I've added both conditions as distinct items to the list of
error conditions, along with the others you suggested (still chewing
over the transaction related errors). Thanks!
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: exceptions in the new apis
Posted by Alan Conway <ac...@redhat.com>.
On 01/21/2010 01:29 PM, Gordon Sim wrote:
> The c++ and python messaging apis need to clearly define the exceptions
> that can be thrown as well as when and where they can be thrown from.
>
> As a start I'd like to compile a list of the important error conditions
> that can occur. I'm hoping other will chip in with changes and additions
> and without too much effort we can get a reasonably complete list agreed
> and then decide how to design the exception hierarchy used to
> communicate them.
>
> The final stage will be determining which exceptions each method in the
> api may throw. There may be some exceptions very specific to particular
> methods that are more obvious when we reach that stage.
>
> * tcp socket fails (or whatever the rdma equivalent is, assuming that is
> a detectable condition)
That should probably be a generic "connection failure" to cover failures of
existing and future transports. Should we distinguish failure to establish
connection from failure of an established connection? Note that if the client is
doing failover the distinction is somewhat blurred.
> * missed heartbeats
>
> * authentication errors
>
> * authorisation errors
>
> * queue not found
>
> * exchange not found
>
> * other address validation errors (e.g. exchange is of different type to
> that specified)
>
> * session terminated by management
>
> * connection terminated by management
>
> * broker side queue limit breached
>
> * exclusive subscriber violation
>
> * feature not supported exception from broker (e,g, unsupported exchange
> type)
>
> * protocol violation errors (by which I mean any sort of framing error
> or problem that is a result of a bug in the library or broker rather
> than being an invalid command by the application)
>
> * internal error in broker, i.e. some as yet unidentified bug,
> misconfiguration or environmental problem
>
* internal error in client: same thing for client-side misconfiguration or bugs.
* Exceeded client-side limitation: a client-side queue is over-full. E.g. user
has not respected flow control limits on the client side.
* Transaction related errors - not sure what the set is, probably just copy from
spec exceptions.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org