>When you say the messages "are indeed purged," do you mean to say (in more >words, to make sure we're clear) "When I reconnect my consumer that has >been offline for longer than the TTL I set, all messages older than the TTL >are expired (as confirmed by an increase in the ExpiredCount JMX attribute >on the queue in question or by some similar mechanism)"?
In case of my project, the consumer is a big message collecting system with gui, so I literally see that there are no new messages after reconnecting it (even though they were sent by the producer and enqueued before) in both cases, with and without given TTL. As soon as the consumer goes online, the pending messages counter starts decreasing, and the number of dequeued messages starts going up. >What about your test procedure causes them to be clearly pending for >more than half a second? Are you saying you're publishing messages far >faster than your consumer can process them and therefore there's a large >backlog? Yes. >How are you determining that message expiration isn't happening? I just see 10k delivered messages on a consumer side. >With this scenario, message expiration could be taking place on either the >broker or the consumer With my scenario messages are pending for more than 500 ms (it takes a dozen or so seconds to dequeue them) therefore I guess it should take place on broker. >But I would expect that 1/2 >second after your last message is produced, your consumer would receive no >further messages to process. That's excactly what I'm trying to achieve. >are the clocks synchronized on whatever machines are >running your producers, consumers, and brokers? In my tests the producer, consumer and broker are running on the same machine, therefore that's not the case since they're using the same system time. -- View this message in context: http://activemq.2283324.n4.nabble.com/ActiveMQ-Messages-are-not-discarded-from-queue-when-they-re-expired-tp4728731p4728770.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
