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 <[email protected]> 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 >> <[email protected]> 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: [email protected] >> 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: [email protected] Web: http://fusesource.com Twitter: davsclaus, fusenews Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/
