If you use session.recover() as intended, instead of letting onMessage throw in error, then you might find it starts behaving in line with expectation.
When onMessage throws in error for auto-ack, it seems the client is currently 'releasing' the delivery to ensure it doesnt get stuck in limbo, however that doesnt cause its AMQP delivery count to be incremented. It should perhaps instead send a 'modified, failed' disposition if the peer indicated it was supported, which would result in the delivery count being incremented. On 2 June 2018 at 16:42, <[email protected]> wrote: > Hi Tim, > > thanks for your response. The JMS spec states: "It is possible for a listener > to throw a RuntimeException; however, this is > considered a client programming error. ... 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, and the > 'JMSXDeliveryCount' message property incremented, for a message redelivered > under these circumstances." > > So, while it may be considered bad practice to throw an exception in a > listener, the JMS provider behavior is specified for that case to a certain > degree. > > For qpid-jms however, when I set the session mode to AUTO_ACKNOWLEDGE then a > message is redelivered endlessly to the message listener and neither the > "JMSRedelivered" nor the "JMSXDeliveryCount" header field are set. I also set > "jms.redeliveryPolicy.maxRedeliveries=3" in the URI with no effect. > > Regards, > Seb > > June 2, 2018 4:32 PM, "Timothy Bish" <[email protected]> wrote: > >> On 06/02/2018 07:41 AM, [email protected] wrote: >> >>> Hi, >>> >>> we are using the qpid-jms client with Artemis 2.6. I am having big troubles >>> getting message >>> rejection/redelivery working as expected. I already opened an issue against >>> Artemis >>> https://issues.apache.org/jira/browse/ARTEMIS-1618 >>> (https://issues.apache.org/jira/browse/ARTEMIS-1618)but the more I play >>> around with my test case >>> the more I wonder if it may be an issue in qpid-jms itself. >>> >>> What I am basically looking for is to consume messages with a >>> MessageListener where in case of an >>> unexpected error during message processing the onMessage() method throws a >>> runtime exception that >>> eventually signals to the broker that the message was not acknowledged. The >>> broker then should try >>> to redeliver the message 3 times and then put it into a pre-configured DLQ. >>> >>> I played around with all kind combination of session modes incl. qpid-jms >>> specific ones and >>> different qpid-jms redeliveryPolicy settings but I am not getting any >>> further. For example when I >>> set the session mode to AUTO_ACKNOWLEDGE in qpid-jms, the message seems to >>> be redelivered locally >>> indefinitely. When I use any other session mode the message is not consumed >>> a second time. >>> >>> The Artemis JIRA issue contains a simple unit test case that can be used to >>> easily reproduce the >>> problem I am having. >>> https://issues.apache.org/jira/secure/attachment/12926230/Artemis1618_AmqpDeadLettering_Test.java >>> (https://issues.apache.org/jira/secure/attachment/12926230/Artemis1618_AmqpDeadLettering_Test.java) >>> >>> I would really appreciate if someone could have a look at it and give me a >>> hint on whether this >>> looks like a bug/limitation in qpid-jms, or if I am doing something >>> completely wrong, or if it >>> seems to be a broker implementation issue. >>> >>> Thanks! >>> >>> Regards, >>> Johan >> >> The JMS specification defines that an exception thrown from onMessage is a >> programming error, so >> I'd say first thing to do is not do that any more and go from there. The >> behavior you want sounds >> like a good candidate for a transacted Session with configuration on the >> redelivery policy that >> controls how many deliveries to allow before the message is no longer >> allowed to be redelivered. >> >> Documentation on the redelivery policy for the Qpid JMS client is here. >> >> http://qpid.apache.org/releases/qpid-jms-0.32.0/docs/index.html#jms-configuration-options >> >> -- Tim Bish >> twitter: @tabish121 >> blog: http://timbish.blogspot.com >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
