I'm working on an application consisting of some modules. In one of those module someone created a topic producer that publishes messages on a topic, but this module hasn't a topic consumer to dequeue the messages. The topic producer sets the time-to-live property to 300000 milliseconds using setTimeToLive()
.
I expect that if there is no consumer, the messages expire within 300000 milliseconds and they are deallocated.
The application is deployed on Tomcat 6.0.36 and it uses an external ActiveMQ server to handle the queues and topics.
Monitoring ActiveMQ with Java VisualVM in the MBeans tab under the topic settings I see that the variable "Enqueue Count" grows, but I don't understand if the time-to-live settings took effect on these messages. I expected to see the counter "ExpiredCount" to increase, but it still remains fixed to 0.
Is there a way to understand if those messages still stay in memory or if they are deallocated?
Thank you very much!
EDIT:
I did some tests using j2ee tutorial examples on netbeans 7.3 using internal glassfish 3.1 as server, monitoring it with jvisualvm and all works as api says:
The JMS API provides no mechanism for browsing a topic. Messages usually disappear from a topic as soon as they appear: if there are no message consumers to consume them, the JMS provider removes them. Although durable subscriptions allow messages to remain on a topic > while the message consumer is not active, no facility exists for examining them.
I read that glassfish uses inside activeMQ so I hope that this is valid also for a standalone ActiveMQ server.
END EDIT.
Queues and Topics are similar when a sender sends messages, but messages are processed differently by a receiver. A queue can have only one consumer, whereas a topic can have multiple subscribers.
Gets the message timestamp as a long . The JMSTimestamp header field contains the time a message was handed off to be sent. It is not the time the message was actually transmitted, because the actual send may occur later due to transactions or other client-side queueing of messages.
The JMS IQ Manager is set to fully concurrent FIFO processing. However, each Collaboration on each integration server retrieves messages as they come in, and is able to commit them unrestricted to the queue.
Use this page to delete specified messages from a destination. The destination must be in a consumption-paused state, and the message state must be either visible, delayed, or ordered. Click Yes to delete the selected JMS messages.
A quote from Creating Robust JMS Applications:
5.1.4 Allowing Messages to Expire
[...]
When the message is published, the specified timeToLive is added to the current time to give the expiration time. Any message not delivered before the specified expiration time is destroyed.
Another quote from the source of javax.jms.Message#getJMSExpiration()
:
When a message's expiration time is reached, a provider should discard it. [...]
Clients should not receive messages that have expired; however, the JMS API does not guarantee that this will not happen.
So in case of non durable subscribers:
So in your case, if there is no consumer, the message is probably not stored at all. Enqueue count is increased, and Expired Count remains at 0. Expired count should only increase in case of a connected (but idle) subscriber.
A quote from How do I find the Size of a Queue
Enqueue Count - the total number of messages sent to the queue since the last restart
Expired Count - the number of messages that were not delivered because they were expired
Note: A test using JBoss 7 shows that in this case the message does not turn up in the client.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With