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