qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Danushka Menikkumbura <danushka.menikkumb...@gmail.com>
Subject Re: JMS Error handling
Date Wed, 25 May 2011 06:59:05 GMT

I think the point here is how you differentiate exceptions which should be
handled at the connection level and those which should be handled at the
session level (or even somewhere down the line).

Another concern in this case is the use of failover mutext as per [1].

[1] - https://issues.apache.org/jira/browse/QPID-3259


On Wed, May 25, 2011 at 1:47 AM, Rajith Attapattu <rajith77@gmail.com>wrote:

> Folks,
> I am trying to tidy up the error handling code in the JMS client and
> is soliciting ideas and feedback.
> I also have rough proposal outlined below.
> Please feel free to make suggestions/improvements for the following
> solution or any alternative ideas that you might think maybe better.
> Currently if there is a session error we throw an exception on most
> JMS methods in addition to notifying via the connection listener.
> This is causing several issues with less than desirable results.
> Besides I wonder if we need to notify the same exception in two
> different ways.
> 1. There is a deadlock due to this.
> 2. Even if the client is notified via a direct exception we still
> throw a connection exception and close the connection (along with all
> other sessions).
> I am wondering if the following is a good idea ?
> 1. If a direct exception can be thrown, then we don't notify via the
> connection listener.
>    Ex. sending messages, creating a producer/consumer etc...
> 2. If a direct exception cannot be thrown (ex. Message Listener case)
> then we notify via the connection listener.
>    In that case we don't care about the rest of the sessions being closed.
> 3. We mention in the documentation, that if a JMS exception is thrown,
> they should recreate their session.
>     If a specific type of exception like
> "MessageNotReadableException" is thrown, then they are advised to
> treat it accordingly.
> Regards,
> Rajith
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message