Q:

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.

A:

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:

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.
A connected client receives the message normally, if it has not yet expired.
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.

