Redelivering Messages to Subscriber

When you use queues and topics in WSO2 Message Broker, messages will be removed from the message store once the message consumers acknowledge that the messages are received.

You can configure message redelivery to a subscriber as follows:

Configuring the maximum number of attempts to redeliver a message

If you want to limit the number of times the message broker attempts to redeliver the message, you can set the maximumRedeliveryAttempts element in the broker.xml file as follows:

<!--Broker will drop the message after the configured number of delivery attempts for each message.-->
	    <maximumRedeliveryAttempts>10</maximumRedeliveryAttempts>

Note that the above configuration specifies the total number of attempts to redeliver the message after the original delivery attempt. For example, when the first attempt to send the message fails, there will be another 10 attempts to redeliver the message. After the maximum number of attempts to redeliver the message are breached, the message is sent to the Dead Letter Channel. This is useful when the client application does not acknowledge the message because an operation on the message failed.

If the message is successfully delivered on a redelivery attempt, the JMSRedelivered field is set to 'true' in the message header, allowing the client to determine whether the message was delivered by the original attempt or on a later attempt.

Delaying message redelivery to a subscriber

A subscriber client can delay the redelivery of messages to the subscriber (when the message has already been rejected). This can be done in two ways: Using a system property, or by using a parameter in the connection URL:

• Using a system property
  

  Any message that comes to the client with the redelivery flag true will get delayed. The delay can be set using a custom system property. New messages that are received by the client does not get blocked due to the redelivered message. Therefore, redelivered messages are unordered.

  When using this feature, it may be necessary to use “Per-Message Acknowledgements” depending on the use case.

  This system property can be set as shown below. This value is given in milliseconds. The default value is 0.

  System.setProperty("AndesRedeliveryDelay", "10000");

  
  

• Using a parameter in the connection URL

  The possibility of specifying the redlivery delay in the connection URL is available only as a WUM update for WSO2 MB 3.2.0. This WUM update is effective from the 5th of April, 2018. For instructions on getting updates for WSO2 MB, see Updating WSO2 Products.

  Once you get the WUM update, be sure to replace all instances of the andes-client-3.2.19.jar used in the subscriber client with the new JAR found in WUM-updated WSO2 MB (<WUM-UPDATED_MB>/client-lib/andes-client-3.2.19.jar).

  
  

  With this option, the expected redelivery delay can be specified in milliseconds in the connection URL by using the redeliverydelay parameter. For example, see the following connection URL, which specifies a redelivery delay of 15000 milliseconds:

  amqp://admin:admin@clientID/carbon?redeliverydelay='15000'&brokerlist='tcp://localhost:5673'

  See Setting the Connection URL for more details on all the paramaters used in the connection URL.