As long as the consumer is holding the queue, the message should not be expired.
Next time it is redelivered (after say a rollback) then the message will be checked again for expired. Implementing the semantic you expect would be troublesome. you would receive the message... hold the ack.. and if you later acked.. what would be the expecation? the message would be duplciated? so.. definitely the expected behavior on any JMS compliant messaging system. On Mon, May 7, 2018 at 8:14 AM, ajitmahadik <ajit.mahadi...@gmail.com> wrote: > We are using ActiveMQ 5.13.4 and ActiveMQ 5.15.3 > > with the below configuration > > <destinationPolicy> > <policyMap> > <policyEntries> > <policyEntry queue=">" advisoryForConsumed="true"> > > <deadLetterStrategy> > <sharedDeadLetterStrategy processExpired="false"/> > </deadLetterStrategy> > </policyEntry> > </policyEntries> > </policyMap> > </destinationPolicy> > > > A producer sends a persisted message on a queue with a TTL of 5 sec. > A consumer consumes a message but without acknowledging it and stays > connected. > > We saw that the queue size=1, inflight=1, and after even waiting for > forever, the message is never expired. > > Is it the expected behavior?? > > We also noticed that when we browse that queue via admin console, only then > the message expires even though it was in InFlight. > > Why the TTL expiry of a message does not behave same in both? > > > > -- > Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html -- Clebert Suconic
