Glas to hear things worked as expected when used as intended. Your expectations on the second case were incorrect. Setting the client side 'maxRedeliveries' to 0 specifically will never result in the redelivery policy being enforced if the client 'releases' the message to the server, since as I mentioned that does not increment the AMQP message delivery count, which is what the consumer will base its redelivery policy decision on when the message arrives next before handing it to the application as the policy hasnt been exceeded. The 'outcome' configuration should make no difference in that case as no outcome ever gets applied due to redelivery policy specifically since it isnt breached.
Feel free to raise a JIRA for the behaviour on throwing from onMessage. Robbie On 2 June 2018 at 21:32, <[email protected]> wrote: > When I am using session.recover() client side redelivery/message rejection > works. > > What doesn't seem to work is that in Artemis is a server-side > max-delivery-attempt value can be specified. > So I expected if I set "jms.redeliveryPolicy.maxRedeliveries" on the client > side to 0 and the "jms.redeliveryPolicy.outcome" to "RELEASE" the broker > would then only attempts redeliver the message to the client as specified by > max-delivery-attempt and then put it into the DLQ. However Artemis still > infinitely tries to redeliver the message. > > Is it worth opening a bug report regarding qpid-jms's behavior to not > increment delivery count > in case a message listener throws a runtime exception? > > June 2, 2018 7:52 PM, "Robbie Gemmell" <[email protected]> wrote: > >> 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. > > --------------------------------------------------------------------- > 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]
