When using message queues in WSO2 Message Broker, messages are removed from the message store when the message consumers acknowledge for the messages were received. There are several Acknowledgement Models acknowledgement models defined in JMS specification 1.1. If the client did not acknowledge for a sent message , broker assumes that message is before the Ack Time-out setting has elapsed, Message Broker assumes the message was not received by the message consumer and try tries to re-deliver redeliver the message. Thus, for the broker to assume that message has been not received by the JMS consumer application it uses "You can configure the Ack Time-out ". For WSO2 Message Broker you can configure this value editing value by opening the qpid-config.xml file.Navigate to in <MB_HOME>/repository/conf/advanced
/ folder and edit editing the following entry.:
Code Block | ||
---|---|---|
| ||
<waitTimes> <!-- Max wait time (in seconds) for aan acknowledgement for a given message from the client --> <maxAckWaitTime>10</maxAckWaitTime> |
There may be a practical scenario where we use "CLIENT_ACKNOWLEDGE" mode or JMS transactions where the client application does not acknowledge the message if some operation on the message fails. If a particular message is being failed at the client side again and again, there should be a way to remove that message from the system after a defined number of message re-deliveries has breached. This is an added functionality to WSO2 Message Broker. To configure this edit following If you want to limit the number of times Message Broker attempts to deliver the message, you can set the maximumNumberOfMessageDeliveryAttempts
entry in qpid-config.xml
file:
Code Block | ||
---|---|---|
| ||
<!--Broker will drop the message after the configured number of delivery attempts for each message.--> <maximumNumberOfMessageDeliveryAttempts>10</maximumNumberOfMessageDeliveryAttempts> |
Note that this is the total number of delivery attempt attempts, not re-delivery attempts. Also When this threshold is reached, the message is dropped from Message Store permanently when above condition is met. permanently removed from the message store, and no further attempts to deliver the message will be made. 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 on its original attempt or on a redelivery attempt.