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:24:47 GMT
> What AMQ version are you using?
Almost the latest release - 5.5.0. 
5.5.1 should only contain the change regarding the LGBL issue of a dependency, or?


> And which AMQ message store do you use?
KahaDB, we use a shared storage for master/slave

 
> 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