activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Tully <gary.tu...@gmail.com>
Subject Re: Implementation of message redelivery delay
Date Tue, 15 Nov 2011 11:44:09 GMT
On 2, the current redelivery mechanism is handled by the consumer. A
new consumer has no history. This is the simplest from the broker
perspective b/c it does not need to persist a message a second or
subsequent times.

Along with the redelivery delay, the redelivery counter is not
persisted, however there was a recent enhancement to allow the
redelivery counter to be persisted, essentially having the broker
rewrite a message on a rollback. This ensures that a user can always
depend on the redelivery flag.
https://issues.apache.org/jira/browse/AMQ-3519

I think a change to pass the redeliveryCount to the redelivery policy
would make sense, such that the policy can determine the delay
independent of the consumer.

Having said all that, for your use case, caching the consumer may be simplest.

On 15 November 2011 11:25, Hubert, Eric <Eric.Hubert@jestadigital.com> wrote:
> Hi Claus,
>
> thanks for your response. Please find my answers and follow-up questions inline!
>
>> Which type of Spring MessageListenerContainer are you using? default or
>> simple.
> DefaultMessageListenerContainer
>
>> And what version of Spring are you using?
> 2.5.6
>
> Both are part of a product we are using and not under our control, but we could certainly
try to influence this, if there is a good reason.
>
>> And what cache level have you configured?
> We experimented with multiple values. In most configurations redelivery stopped to then
to work completely. We also used multiple different connection factories including Spring's
CachingConnectionFactory.
>
>> You need CACHE_CONSUMER to keep re-using the same consumer.
> This is the point of my question. Does this make sense to cache (not pool) consumers?
Isn't this rather an anti pattern?
> I don't understand why the implementation is forcing the use of the same instance of
the consumer. I would be very happy if I would understand this.
> It does neither sound logical nor correct to me.
>
> So to me there are two ways:
> 1) trying to fix the symptoms of the problem and looking for a way that always the same
consumer is used.
> 2) look for ways to change ActiveMQs redelivery implementation to make it consumer neutral
>
> Did someone ever think about option 2? Is this not feasible for some reason? Is there
some positive aspect regarding the current implementation?
>
> Many thanks,
>   Eric
>
>
>> On Tue, Nov 15, 2011 at 3:36 AM, Hubert, Eric
>> <Eric.Hubert@jestadigital.com> 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 delay.
>> > 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]
>> > http://activemq.2283324.n4.nabble.com/RedeliveryPolicy-not-working-with-
>> Springs-DefaultMessageListenerContainer-td4039575.html
>> >
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> FuseSource
>> Email: cibsen@fusesource.com
>> Web: http://fusesource.com
>> Twitter: davsclaus, fusenews
>> Blog: http://davsclaus.blogspot.com/
>> Author of Camel in Action: http://www.manning.com/ibsen/
>



-- 
http://fusesource.com
http://blog.garytully.com

Mime
View raw message