Hi Tim,
The main reason for setting a TTL on messages is to protect the broker’s
database from filling up. If the broker does not honor that, than it is
prone to a denial-of-service. All it takes is a user that does not
acknowledge messages.
This is a very serious flaw in ActiveMQ that anyone ca
Ajit,
I agree with Clebert's statement that the message, once delivered to the
consumer, should not be within the broker's control to expire. Once it's
been delivered, it's outside of the broker's control and is the client's
responsibility to deal with appropriately.
However, I agree with your as
clebertsuconic wrote
> As long as the consumer is holding the queue, the message should not
> be expired.
But then why when we browse the queue from ActiveMQ admin console the
message expired even though it was not acknowledged by the client?
--
Sent from: http://activemq.2283324.n4.nabble.co
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 i
We are using *ActiveMQ 5.13.4* and *ActiveMQ 5.15.3*
with the below configuration
A producer sends a persisted message on a queue with a TTL of 5 sec.
A consumer consumes a message but without acknowledg
We are using ActiveMQ 5.13.4 and ActiveMQ 5.15.3
with the below configuration
A producer sends a persisted message on a queue with a TTL of 5 sec.
A consumer consumes a message but without acknowledgin
