[
https://issues.apache.org/jira/browse/QPIDJMS-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16578874#comment-16578874
]
Dan Langford commented on QPIDJMS-388:
--------------------------------------
what is particularly interesting about this behavior is that if i use
Spring-JMS and throw an exception from my method annotated with @JmsListener
the account does increase. so Spring-JMS must be juggling the consumer,
session, and or connection in a way that behaves a little more as expected. as
a result our current work around for our users that are required certain
compliant behavior around redeliveries is to use Spring-JMS. i have on my TODO
list to determine what Spring-JMS is doing to get the desired behavior for our
java clients who dont want to use Spring.
> Unhandled RuntimeException in MessageListener#onMessage does not increment
> AMQP delivery count in AUTO_ACK
> ----------------------------------------------------------------------------------------------------------
>
> Key: QPIDJMS-388
> URL: https://issues.apache.org/jira/browse/QPIDJMS-388
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
> Affects Versions: 0.32.0
> Reporter: Johan Stenberg
> Priority: Minor
> Attachments: QpidJms388_RuntimeExectionInOnMessageTest.java
>
>
> The JMS spec states: "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
> 'JMSRedelivered' message header field will be set, and the
> 'JMSXDeliveryCount' message property incremented, for a message redelivered
> under these circumstances."
> Currently qpid-jms however is not incrementing the deliveryCount or setting
> the redelivered message header to true when a listener throws a
> runtimeexception while in AUTO_ACK.
> This results in "jms.redeliveryPolicy.maxRedeliveries" being ignored and
> endless redelivery attempts.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]