Message deadlettering using JMS and deferred messages about azure-service-bus-java

[Draczech]

I've tested the suggested types of acknowledgement and ACCEPTED, REJECTED and RELEASED are working as expected. But when I tried using the MODIFIED_FAILED mode, I expected the message to get redelivered as many times as is the Max Delivery Count property value on the queue I was working with. And that I could see it later in the DLQ with the usual "delivery count exceeded" comment.

But instead it was behaving exactly the same way the MODIFIED_FAILED_UNDELIVERABLE mode - message got deferred instantly.

[yvgopal]

DEFERRED is a valid state for a message in service bus. A deferred message is in the same queue, but not at the top of the queue any more. It can be received only with a special operation called 'receiveBySequenceNumber'. Because of AMQP doesn't natively understand Deferred as a state, it is internally implemented as MODIFIED outcome with undeliverable-here set to true.
So if an AMQP client receives a message, but if instead of accepting the delivery, it sends a delivery state of MODIFIED means the message is abandoned and delivery count is incremented. If the receiver sends a delivery state of MODIFIED with undeliverable-here set to true, the message is deferred. In your case, the exception is thrown in the processing code, your JMS library is sending MODIFIED with undeliverable-here set to true, which is causing the message to be deferred. If you can tweak that, your problem will be solved.
Instead, your client can send a disposition with state REJECTED and the message will be dead-lettered right away.

[binzywu]

to add.

1. you need to use client ack mode
2. take a look at this: https://issues.apache.org/jira/browse/QPIDJMS-121 with latest qpid JMS you can set the ack type to amqp.
3. below is the map between AMQP disposition and Service Bus semantics.

ACCEPTED = 1; -> Complete()
REJECTED = 2; -> DeadLetter()
RELEASED = 3; (just unlock the message in service bus, will then get redelivered)
MODIFIED_FAILED = 4; -> Abandon() which increases delivery count
MODIFIED_FAILED_UNDELIVERABLE = 5; -> Defer()

[Draczech]

Thanks for the suggestion! I'll try using it as soon as I get back to work after this weekend.
Is this approach commonly used? As this is the first time I've heard of it.

[binzywu]

@Draczech sorry for delayed response. Could you please turn on trace and past the traced frame for MODIFIED_FAILED?

Trace can be turned on as explained here: https://qpid.apache.org/releases/qpid-jms-0.23.0/docs/index.html#logging

[Draczech]

SorryI could not get to the issue earlier. Now I have some time available for improving my messaging library with different types of ACK as described above so I am back on the issue...

I tried logging what exactly happens on using MODIFIED_FAILED ack. Apparently the message is redelivered immediately which results in expiration I guess as I have JmsRedeliveryPolicy set for 0 redeliveries (as they used to cause some trouble earlier).
You can see the described behaviour in log: message_delivery_log.txt

I thought that the JmsRedeliveryPolicy works for local redelivery only. And that if I use RELEASED as default outcome of JmsRedeliveryPolicy, the DeliveryCount property on the message in Service Bus Queue message should not change. Apparently I was wrong. The message always ends up with DeliveryCount at 3 and at deferred state. Which leads me to another question:

Is the delivery count on ConnectionFactory connected to Max Delivery Count in Service Bus?

[qwazer]

@axisc HI. What the reason to close?