Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

JMS topic time to live

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.

like image 253
Stefania Avatar asked Aug 29 '13 09:08

Stefania


People also ask

What is the difference between JMS queue and Topic?

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.

What is JMS timestamp?

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.

Is JMS a FIFO?

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.

How do you delete messages on JMS topic?

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.


1 Answers

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:

  1. The server sends the message to each connected subscriber. The expiry value in the message is set to "current time + TTL". Disconnected subscribers will not receive anything.
  2. A connected client receives the message normally, if it has not yet expired.
  3. If a connected client takes too long before receiving a message (the message has expired), it might be discarded by the server (possibly in case the server has not yet pushed it into the client's buffer) or it can be received (possibly in case the message is already in the client's buffer).

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.

like image 134
Beryllium Avatar answered Oct 13 '22 00:10

Beryllium