On Tue, Jan 26, 2010 at 7:19 AM, Gordon Sim <[email protected]> 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:[email protected] > > -- Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/ --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
