activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <claus.ib...@gmail.com>
Subject Re: Implementation of message redelivery delay
Date Tue, 15 Nov 2011 11:37:45 GMT
What AMQ version are you using?
And which AMQ message store do you use?


On Tue, Nov 15, 2011 at 12:25 PM, 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/
>



-- 
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/

Mime
View raw message