You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Hubert, Eric" <Er...@jestadigital.com> on 2011/11/15 03:36:32 UTC
Implementation of message redelivery delay
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
RE: Implementation of message redelivery delay
Posted by "Hubert, Eric" <Er...@jestadigital.com>.
> 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
> <Er...@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
> >> <Er...@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/
Re: Implementation of message redelivery delay
Posted by Claus Ibsen <cl...@gmail.com>.
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
<Er...@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
>> <Er...@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/
Re: Implementation of message redelivery delay
Posted by Gary Tully <ga...@gmail.com>.
go ahead and make it better, more intuitive. Passing in the message makes sense.
The backward compatibility requirements are on the setters such that
existing config will not break.
http://activemq.apache.org/redelivery-policy.html
On 15 November 2011 16:02, Hubert, Eric <Er...@jestadigital.com> wrote:
> Gary, I raised AMQ-3597 [1].
>
> And of course we are willing to help with the implementation and test case creation, if we are able to.
>
> As we are still struggling with the "simple" setup of consumer-based redelivery, this may take some time though. We would like to get a better understanding of the code before we start looking into a very concrete issue.
>
> We have also been slightly confused about the specific handling of the consumer for the case of the initial delay, until we found out, that the initial delay is only copied to the redeliveryDelay member of the RedeliveryPolicy at class instantiation time, so that if someone sets this property via a Spring bean (setter injection) the getNextRedeliveryDelay(long) if called with 0 will never pickup the configured value. Therefore the differentiation is probably moved to the user of the class, although this is not really intuitive.
>
> Is everything of the RedeliveryPolicy class (including the getNextRedeliveryDelay(long) which does not really represent a conventional getter) considered to be part of the public API?
> Changing from a delay to a redeliveryCount should result in rather small implementation changes (both inside the method implementation as well as the broker internal usages), but a bad smell in terms of API change.
> Contrary adding another operation with a different name and deprecating the existing one would not be of much value either, once all internal usages are changed.
> Thinking about potential future requirements and noticing RedeliveryPolicy is no interface, but a concrete class it might also be an option to not pass in just the redelivery counter, but possibly the message. This could allow the use of other metadata to influence the way the delivery delay is calculated.
>
> If you have any preference or some don't, please just shortly comment. Otherwise I will update the issue once we look into the implementation. If someone wants to beat us, we are of course all open. ;-)
>
> Thanks,
> Eric
>
> [1] https://issues.apache.org/jira/browse/AMQ-3597
>
>> >> 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?
>>
>> We are actively trying to lock down 5.6[1] but this change is a nice
>> candidate and would require a major version due to the api change so
>> now is a good time.
>>
>> Can you raise a jira issue for this or even submit a patch with a test
>> case and we can integrate it.
>>
>
--
http://fusesource.com
http://blog.garytully.com
RE: Implementation of message redelivery delay
Posted by "Hubert, Eric" <Er...@jestadigital.com>.
Gary, I raised AMQ-3597 [1].
And of course we are willing to help with the implementation and test case creation, if we are able to.
As we are still struggling with the "simple" setup of consumer-based redelivery, this may take some time though. We would like to get a better understanding of the code before we start looking into a very concrete issue.
We have also been slightly confused about the specific handling of the consumer for the case of the initial delay, until we found out, that the initial delay is only copied to the redeliveryDelay member of the RedeliveryPolicy at class instantiation time, so that if someone sets this property via a Spring bean (setter injection) the getNextRedeliveryDelay(long) if called with 0 will never pickup the configured value. Therefore the differentiation is probably moved to the user of the class, although this is not really intuitive.
Is everything of the RedeliveryPolicy class (including the getNextRedeliveryDelay(long) which does not really represent a conventional getter) considered to be part of the public API?
Changing from a delay to a redeliveryCount should result in rather small implementation changes (both inside the method implementation as well as the broker internal usages), but a bad smell in terms of API change.
Contrary adding another operation with a different name and deprecating the existing one would not be of much value either, once all internal usages are changed.
Thinking about potential future requirements and noticing RedeliveryPolicy is no interface, but a concrete class it might also be an option to not pass in just the redelivery counter, but possibly the message. This could allow the use of other metadata to influence the way the delivery delay is calculated.
If you have any preference or some don't, please just shortly comment. Otherwise I will update the issue once we look into the implementation. If someone wants to beat us, we are of course all open. ;-)
Thanks,
Eric
[1] https://issues.apache.org/jira/browse/AMQ-3597
> >> 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?
>
> We are actively trying to lock down 5.6[1] but this change is a nice
> candidate and would require a major version due to the api change so
> now is a good time.
>
> Can you raise a jira issue for this or even submit a patch with a test
> case and we can integrate it.
>
Re: Implementation of message redelivery delay
Posted by Gary Tully <ga...@gmail.com>.
>> 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?
We are actively trying to lock down 5.6[1] but this change is a nice
candidate and would require a major version due to the api change so
now is a good time.
Can you raise a jira issue for this or even submit a patch with a test
case and we can integrate it.
[1] https://issues.apache.org/jira/browse/AMQ/fixforversion/12317974#atl_token=A5KQ-2QAV-T4JA-FDED%7Cb89b8b5cabbe5eb6fbb0d9e0d93ed1bbc143ad4d%7Clin&selectedTab=com.atlassian.jira.plugin.system.project%3Aversion-issues-panel
--
http://fusesource.com
http://blog.garytully.com
RE: Implementation of message redelivery delay
Posted by "Hubert, Eric" <Er...@jestadigital.com>.
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 <Er...@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
> >> <Er...@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
Re: Implementation of message redelivery delay
Posted by Gary Tully <ga...@gmail.com>.
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 <Er...@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
>> <Er...@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
RE: Implementation of message redelivery delay
Posted by "Hubert, Eric" <Er...@jestadigital.com>.
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
> <Er...@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/
Re: Implementation of message redelivery delay
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
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
<Er...@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/