[
https://issues.apache.org/jira/browse/QPID-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12990174#comment-12990174
]
Keith Wall commented on QPID-1670:
----------------------------------
It seems to me that it is reasonable for java.lang.Errors thrown within
onMessage to cause the Dispatcher thread to die. Errors represent abnormal JVM
conditions and the Javadoc for java.lang.Error specifically advises against
trying to handle these error.
However, I think it would improve the client if it were changed to log the
exception to the application log (i.e. log via SLF4J) rather than relying on
the logging to stderr provided as default behaviour from the JVM's
ThreadGroup.uncaughtException. This would allow any log scraping employed by
the user to detect the condition and respond accordingly (generate an alert, or
restart the process)..
Attaching patch that implements/registers an UncaughtExceptionHandler which
logs uncaught exceptions that abruptly terminate threads to the application log
(via SLF4J) with supporting system and unit tests
> 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
>
> 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.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
