Gary Tully created AMQ-3894:
-------------------------------
Summary: Add support for Broker based redelivery
Key: AMQ-3894
URL: https://issues.apache.org/jira/browse/AMQ-3894
Project: ActiveMQ
Issue Type: New Feature
Components: Broker
Reporter: Gary Tully
Assignee: Gary Tully
redelivery is handled by the consumer, so client side. messages pending
redelivery are seen as inflight by the broker and not available to other
consumers. It is possible to break the order constraint and receive messages
backed up behind a message pending redelivery, but this is all local to the
client consumer.
When redelivery is exhausted, the message is returned to the broker with a
poison ack, which the broker responds by removing the message and doing Dead
letter queue processing (DLQ).
This enhancement will allow a replacement of DLQ handling that will handle
redelivery. It is based on the ideas outlined and implemented by a camel route
in https://issues.apache.org/jira/browse/AMQ-2710
The idea is a BrokerPlugin will override sendToDeadLetterQueue and resend the
message to the original destination in accordance with a matching
RedeliveryPolicy. The resend will use the broker schedular to implement the
delayed send after the message has been acked as poison by the consumer.
So the message will essentially be enqueued at the tail of the queue and
dispatched again to any available consumer.
If retries are exceeded or there is no matching redelivery policy for a
destination, normal DLQ processing will take place.
This will work in conjunction with consumer/client redelivery exhaustion or
using a redelivery policy in the url query of
jms.redeliveryPolicy.maximumRedeliveries=0
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
