Awesome. Knowing the final outcome helps in case this ever pops up again.
Sent from my iPhone > On Jan 24, 2014, at 7:51 AM, "johnd [via ActiveMQ]" > <ml-node+s2283324n4676768...@n4.nabble.com> wrote: > > artnaseef wrote > Cool - you're welcome. > > Note that plugin may be valuable if your broker clocks ever get far > out-of-sync, so you might want to look more closely at why the plugin was > whacking the timeouts. Note that I'm saying this with only a brief look at > that code, so I can't say for sure right now that it can work the way you > need. > Both brokers on the same machine (at the moment!) so not an issue. I'll bare > this in mind though for the future.... > > I think I know why it whacks the timeouts though - it was configured like > this: > <timeStampingBrokerPlugin zeroExpirationOverride="1000" > ttlCeiling="60000" futureOnly="true"/> > !! > > I should have picked this up sooner really but had a blind spot as I thought > I had only added some plugins for logging/traceability purposes. > > Cheers - and thanks again, > > John > > > If you reply to this email, your message will be added to the discussion > below: > http://activemq.2283324.n4.nabble.com/Persistent-messages-moving-to-DLQ-when-consumer-not-active-tp4676652p4676768.html > To unsubscribe from Persistent messages moving to DLQ when consumer not > active, click here. > NAML -- View this message in context: http://activemq.2283324.n4.nabble.com/Persistent-messages-moving-to-DLQ-when-consumer-not-active-tp4676652p4676798.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
