qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aidan Skinner (JIRA)" <qpid-...@incubator.apache.org>
Subject [jira] Updated: (QPID-1670) Errors thrown from onMessage can kill the dispatcher
Date Tue, 17 Mar 2009 15:16:50 GMT

     [ https://issues.apache.org/jira/browse/QPID-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Aidan Skinner updated QPID-1670:
--------------------------------

          Description: 
BasicMessageConsumer.notifyMessage catches Exception and handles it, but unchecked throwables
will cause the Dispatcher thread in the Session to terminate after logging. It does not kill
the session. 

The JMS spec has this to say:
4.5.2 Asynchronous Delivery
A client can register an object that implements the JMS MessageListener
interface with a MessageConsumer. As messages arrive for the consumer, the
provider delivers them by calling the listener's onMessage method.
It is possible for a listener to throw a RuntimeException; however, this is
considered a client programming error. Well-behaved listeners should catch
such exceptions and attempt to divert messages causing them to some form of
application-specific 'unprocessable message' destination.
The result of a listener throwing a RuntimeException depends on the session's
acknowledgment mode.
• AUTO_ACKNOWLEDGE or DUPS_OK_ACKNOWLEDGE - the message
will be immediately redelivered. The number of times a JMS provider will
redeliver the same message before giving up is provider-dependent. The
JMSRedelivered message header field will be set for a message redelivered
under these circumstances.
• CLIENT_ACKNOWLEDGE - the next message for the listener is delivered.
If a client wishes to have the previous unacknowledged message
redelivered, it must manually recover the session.
• Transacted Session - the next message for the listener is delivered. The client
can either commit or roll back the session (in other words, a
RuntimeException does not automatically rollback the session).
JMS providers should flag clients with message listeners that are throwing
RuntimeExceptions as possibly malfunctioning.



  was:
BasicMessageConsumer.notifyMessage catches Exception and handles it, but unchecked exceptions
(eg. RuntimeException) will cause the Dispatcher thread in the Session to terminate after
logging. It does not kill the session. 

The JMS spec has this to say:
4.5.2 Asynchronous Delivery
A client can register an object that implements the JMS MessageListener
interface with a MessageConsumer. As messages arrive for the consumer, the
provider delivers them by calling the listener's onMessage method.
It is possible for a listener to throw a RuntimeException; however, this is
considered a client programming error. Well-behaved listeners should catch
such exceptions and attempt to divert messages causing them to some form of
application-specific 'unprocessable message' destination.
The result of a listener throwing a RuntimeException depends on the session's
acknowledgment mode.
• AUTO_ACKNOWLEDGE or DUPS_OK_ACKNOWLEDGE - the message
will be immediately redelivered. The number of times a JMS provider will
redeliver the same message before giving up is provider-dependent. The
JMSRedelivered message header field will be set for a message redelivered
under these circumstances.
• CLIENT_ACKNOWLEDGE - the next message for the listener is delivered.
If a client wishes to have the previous unacknowledged message
redelivered, it must manually recover the session.
• Transacted Session - the next message for the listener is delivered. The client
can either commit or roll back the session (in other words, a
RuntimeException does not automatically rollback the session).
JMS providers should flag clients with message listeners that are throwing
RuntimeExceptions as possibly malfunctioning.



    Affects Version/s: 0.6
        Fix Version/s:     (was: 0.5)
              Summary: Errors thrown from onMessage can kill the dispatcher  (was: runtime
exceptions from onMessage can kill the dispatcher)

I was about to fix this, but we do actually handle RuntimeException properly. What we don't
handle are things that don't extend Exception, such as Error. I'm not sure that we want to
handle those this way though, death may be a more appropriate response. 

> Errors thrown from onMessage can kill the dispatcher
> ----------------------------------------------------
>
>                 Key: QPID-1670
>                 URL: https://issues.apache.org/jira/browse/QPID-1670
>             Project: Qpid
>          Issue Type: Bug
>          Components: Java Client
>    Affects Versions: 0.5, 0.6
>            Reporter: Aidan Skinner
>            Assignee: Aidan Skinner
>            Priority: Blocker
>
> BasicMessageConsumer.notifyMessage catches Exception and handles it, but unchecked throwables
will cause the Dispatcher thread in the Session to terminate after logging. It does not kill
the session. 
> The JMS spec has this to say:
> 4.5.2 Asynchronous Delivery
> A client can register an object that implements the JMS MessageListener
> interface with a MessageConsumer. As messages arrive for the consumer, the
> provider delivers them by calling the listener's onMessage method.
> It is possible for a listener to throw a RuntimeException; however, this is
> considered a client programming error. Well-behaved listeners should catch
> such exceptions and attempt to divert messages causing them to some form of
> application-specific 'unprocessable message' destination.
> The result of a listener throwing a RuntimeException depends on the session's
> acknowledgment mode.
> • AUTO_ACKNOWLEDGE or DUPS_OK_ACKNOWLEDGE - the message
> will be immediately redelivered. The number of times a JMS provider will
> redeliver the same message before giving up is provider-dependent. The
> JMSRedelivered message header field will be set for a message redelivered
> under these circumstances.
> • CLIENT_ACKNOWLEDGE - the next message for the listener is delivered.
> If a client wishes to have the previous unacknowledged message
> redelivered, it must manually recover the session.
> • Transacted Session - the next message for the listener is delivered. The client
> can either commit or roll back the session (in other words, a
> RuntimeException does not automatically rollback the session).
> JMS providers should flag clients with message listeners that are throwing
> RuntimeExceptions as possibly malfunctioning.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org


Mime
View raw message