ActiveMQ Broker Fails To Respect Max Delivery Attempts Following Client Crash

0
votes

I am using ActiveMQ 5.15.14 with a customized redelivery policy on the broker to deliver bad messages to the DLQ after one redelivery attempt to my clients.

When using a Spring Boot based client this works correctly when an exception is thrown from within the Java code. However if the Java client is crashes or is abruptly terminated, the redelivery count is increased in the broker but the message is never sent to the DLQ regardless of the number of redelivery attempts that are made.

Is there a way to have the broker move messages to the DLQ based on a client disconnecting instead of reporting an actual exception?

1
javaspring-bootactivemq

1 Answers

0
votes

You could open a JIRA ticket for feature request, but I'm not sure it would gain much traction.

Consider that the broker doesn't really know if the consumer ever got the message. With this approach, you would get a large number of messages moved to DLQ during a maintenance window, or flaky network situation. Also, moving valid messages to the DLQ on client disconnects will through any reasonable delivery of messages in order.

Generally, for messaging error handling it is best to separate:

  1. 'bad message' (ie incorrect formatted JSON)
  2. 'retry delivery' (ie consumer was not able to receive messages).

Generally, users want immediate move to DLQ on #1 and retry forever on #2