ActiveMQ
  1. ActiveMQ
  2. AMQ-3894

Add support for Broker based redelivery

    Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 5.7.0
    • Component/s: Broker
    • Labels:
      None

      Description

      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

        Issue Links

          Activity

          Hide
          Gary Tully added a comment - - edited

          Implementation of per destination broker redelivery using per destination redelivery policy via redeliveryPlugin and schedulerSupport.
          Relevant xml config:

          
              <broker xmlns="http://activemq.apache.org/schema/core"    schedulerSupport="true" >
          
                  <plugins>
                      <redeliveryPlugin fallbackToDeadLetter="true" sendToDlqIfMaxRetriesExceeded="true">
                          <redeliveryPolicyMap>
                              <redeliveryPolicyMap>
                                  <redeliveryPolicyEntries>
                                      <!-- a destination specific policy -->
                                      <redeliveryPolicy queue="SpecialQueue" maximumRedeliveries="4" redeliveryDelay="10000" />
                                  </redeliveryPolicyEntries>
                                  <!-- the fallback policy for all other destinations -->
                                  <defaultEntry>
                                      <redeliveryPolicy maximumRedeliveries="4" initialRedeliveryDelay="5000" redeliveryDelay="10000" />
                                  </defaultEntry>
                              </redeliveryPolicyMap>
                          </redeliveryPolicyMap>
                      </redeliveryPlugin>
                  </plugins>
          

          http://svn.apache.org/viewvc?rev=1352902&view=rev

          Show
          Gary Tully added a comment - - edited Implementation of per destination broker redelivery using per destination redelivery policy via redeliveryPlugin and schedulerSupport. Relevant xml config: <broker xmlns= "http: //activemq.apache.org/schema/core" schedulerSupport= " true " > <plugins> <redeliveryPlugin fallbackToDeadLetter= " true " sendToDlqIfMaxRetriesExceeded= " true " > <redeliveryPolicyMap> <redeliveryPolicyMap> <redeliveryPolicyEntries> <!-- a destination specific policy --> <redeliveryPolicy queue= "SpecialQueue" maximumRedeliveries= "4" redeliveryDelay= "10000" /> </redeliveryPolicyEntries> <!-- the fallback policy for all other destinations --> <defaultEntry> <redeliveryPolicy maximumRedeliveries= "4" initialRedeliveryDelay= "5000" redeliveryDelay= "10000" /> </defaultEntry> </redeliveryPolicyMap> </redeliveryPolicyMap> </redeliveryPlugin> </plugins> http://svn.apache.org/viewvc?rev=1352902&view=rev
          Hide
          Timothy Bish added a comment -

          http://activemq.2283324.n4.nabble.com/Redelivery-policy-broken-in-5-7-0-td4658304.html

          Changes here lead to configuration troubles with RedeliverPolicy in XML config. We should see if we can remove the afterPropertiesSet method that's enforcing the destination by non-null or default to AnyDestination in RedeliveryPolicy.

          Show
          Timothy Bish added a comment - http://activemq.2283324.n4.nabble.com/Redelivery-policy-broken-in-5-7-0-td4658304.html Changes here lead to configuration troubles with RedeliverPolicy in XML config. We should see if we can remove the afterPropertiesSet method that's enforcing the destination by non-null or default to AnyDestination in RedeliveryPolicy.
          Hide
          Gary Tully added a comment -

          removed the enforcement of a destination on policy entry - not required for default entries

          Show
          Gary Tully added a comment - removed the enforcement of a destination on policy entry - not required for default entries
          Hide
          Martin Lichtin added a comment -

          A useful feature!
          XML tidbit, it's <redeliveryPolicyEntries>

          Also, when setting sendToDlqIfMaxRetriesExceeded="false", a message gets silently dropped
          when max retries is reached. Expected, and if so, worth documenting?
          I'd have expected the message stays in the queue.

          Show
          Martin Lichtin added a comment - A useful feature! XML tidbit, it's <redeliveryPolicyEntries> Also, when setting sendToDlqIfMaxRetriesExceeded="false", a message gets silently dropped when max retries is reached. Expected, and if so, worth documenting? I'd have expected the message stays in the queue.
          Hide
          Gary Tully added a comment -

          @Martin thanks for the feedback. Yep, sendToDlqIfMaxRetriesExceeded=false is the same as not having a dlq configured for a destination, because the message has been poisoned ack by the consumer so it has gone from the queue.

          Show
          Gary Tully added a comment - @Martin thanks for the feedback. Yep, sendToDlqIfMaxRetriesExceeded=false is the same as not having a dlq configured for a destination, because the message has been poisoned ack by the consumer so it has gone from the queue.

            People

            • Assignee:
              Gary Tully
              Reporter:
              Gary Tully
            • Votes:
              1 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development