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