I was faced with strange bug in ActiveMQ-CPP library recently.
I just wanted to make sure that message broker (ActiveMQ) redelivers not acknowledged messages to the consumer applying some delay. For example 10 seconds.
Let’s say that consumer processes message and some error occurs like there is no connectivity to the external system where processed message is stored. I do not want the message to be lost but rather returned to the broker and redelivered after some time.
Quick look at the API and documentation and it is clear that such behavior can be implemented using RedeliveryPolicy.
There are some properties which can be used to adjust the policy:
| Option Name | Default | Description |
|---|---|---|
| cms.RedeliveryPolicy.backOffMultiplier | 5.0 | Used to extend the redelivery window when the _useExponentialBackOff option is enabled. |
| cms.RedeliveryPolicy.collisionAvoidancePercent | 15 | Percentage of randomness to add to redelivery backoff to keep multiple consumers in a rollback from redelivering at the same time. |
| cms.RedeliveryPolicy.initialRedeliveryDelay | 1000 | Amount of time to wait before starting redeliveries, in milliseconds. |
| cms.RedeliveryPolicy.maximumRedeliveries | 6 | Maximum number of time to attempt a redelivery before giving up and NAck’ing the message. |
| cms.RedeliveryPolicy.useCollisionAvoidance | false | Should the Random avoidance percentage be added into the redelivery delay. |
| cms.RedeliveryPolicy.useExponentialBackOff | false | Should redeliveries be slowed on each cycle. |
Unfortunately, even if I tried almost all possible combination I could not forced the broker to redeliver messages after specified redelivery delay. Messages came back to the consumer immediately. It caused really high processor utilization and, what is more, log files were growing very quickly.
As last resort I dived into library source code and that is what I found there:
if( internal->redeliveryDelay > 0 && !this->internal->unconsumedMessages->isClosed() ) {
// TODO - Can't do this until we can control object lifetime.
// Start up the delivery again a little later.
// this->internal->scheduler->executeAfterDelay(
// new StartConsumerTask(this), internal->redeliveryDelay);
start();
} else {
start();
}
That must be a joke… API gives you a way to set redelivery delay, documentation says it can be done… But that is what you find in the source code.
Just to be proper I use 3.4.5 version of the library and the bug is fixed in 3.5.0 version.