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]
