activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <>
Subject Re: Implementation of message redelivery delay
Date Tue, 15 Nov 2011 08:03:23 GMT

Which type of Spring MessageListenerContainer are you using? default or simple.
And what version of Spring are you using?
And what cache level have you configured? You need CACHE_CONSUMER to
keep re-using the same consumer.

On Tue, Nov 15, 2011 at 3:36 AM, Hubert, Eric
<> wrote:
> Hi amq devs,
> I know that this is basically a user type configuration question and the very first thing
a colleague of mine was doing after checking all available documentation on ActiveMQ regarding
this topic was posting a question to the user list [1].
> As there is so far no reply and I invested quite some minutes digging through the source
code, I'd like to ask some code/design related questions which are hopefully on topic and
whose answers will help us to overcome our current problems.
> We use a SpringMessageListenerContainer and configured the used connection factory with
the redelivery policy we like to use. As the code in this area does not contain any debug
or trace logs, we debugged the ActiveMQ code around:
> org.apache.activemq.ActiveMQMessageConsumer#rollback
> were we can find this code handling the redelivery logic:
> MessageDispatch lastMd = deliveredMessages.getFirst();
> final int currentRedeliveryCount = lastMd.getMessage().getRedeliveryCounter();
> if (currentRedeliveryCount > 0) {
>    redeliveryDelay = redeliveryPolicy.getNextRedeliveryDelay(redeliveryDelay);
> } else {
>    redeliveryDelay = redeliveryPolicy.getInitialRedeliveryDelay();
> }
> At this point we could also easily validate that all our properties provided on the factory
were correctly propagated to the ActiveMQConnection (initialRedeliveryDelay, backOffMultiplier,
maximumRedeliveryDelay, etc.) and redelivery actually works, but not using the correct redelivery
> We can also see why the redeliveryDelay does not increase with each retry attempt as
expected/configured. Each time the breakpoint is hit a new consumer instance is used, so the
redeliveryDelay (member of the consumer is "reset" to zero al the time).
> What I did not get is why this property is no provider specific property on the message
alongside the redeliveryCounter, but rather stored with a consumer instance?
> Is it expected that the consumer instance will not change? Is this a major limitation
of the current implementation or do I simply did not get the idea behind the implementation
as I'm completely new to the code?
> What if there are multiple listeners even on different machines? How to share the current
redelivery delay if this information is not designed as meta data of the message?
> Many thanks for anyone who is able and willing to shed some light on this. Please also
respond if this is indeed a bug or at least a limitation which should be removed! As this
is currently a blocker for us to move on with ActiveMQ we would be willing to support and
look deeper into the code and check whether we can be able to support/come up with some improvement
ideas and/or a patch.
> Side questions out of interest:
> Are you guys currently more actively working on the next v5 maintenance release (5.6)
or towards the next major (6.0)? Looking at both trunk and Jira all speaks for 5.6. Is Apollo
intended to become "the ActiveMQ 6" or the successor at some point? Looking at the commits
of Apollo I got the first impression Hiram is currently working more or less alone on the
Apollo code base.
> Regards,
>   Eric
> [1]

Claus Ibsen
Twitter: davsclaus, fusenews
Author of Camel in Action:

View raw message