activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hubert, Eric" <Eric.Hub...@jestadigital.com>
Subject RE: Implementation of message redelivery delay
Date Tue, 15 Nov 2011 12:50:45 GMT
Hi Gary,

many thanks for your reply as well!

> 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.
I see. In our scenario we have multiple listeners on different machines for HA and I was also
thinking about the case were one of those listeners crashes. So in this case another listener
would start with a "fresh" redelivery process. I'm also not quite sure on how consumer caching
affects performance in terms of concurrency with multiple threads listening on a queue.

> 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
Thanks for this pointer.

> 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.
Yes, this is exactly how I was originally anticipating the implementation would work. What
are the plans regarding releasing 5.6? Any chance that such a change could be included?

> Having said all that, for your use case, caching the consumer may be
> simplest.
Yes, sounds simple - but at the moment we could not even get this simple approach to work.
Once we configured the cache level CACHE_CONSUMER we did not hit the rollback logic as well.
It looked like the activemq session was no longer transacted. 
We currently use auto acknowledgement and have not configured the session to be transacted
(we manage the transaction on a user level by calling suspend, resume, commit, rollback directly).
Setting the cache level to CACHE_AUTO the session seems to be transacted and the rollback
logic handling including redelivery checks takes place.
We need to further debug the code to find out what's different regarding transaction handling
once switching the cache level.

Sounds all strange to me, but these are just our first observations... We need to invest a
bit more time to debug and hopefully understand the whole integration of Spring and ActiveMQ
at this point.

If you have further pointers, they would be of course very welcome.

Thanks,
   Eric



> 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