1.4.x Topic Subscriber and TTL'ed Messages

[chacs]

Hi,

JBoss Messaging version 1.4.x

We have a JMS Topic where we post messages with TTL of (say) 2 weeks.

Our clients create durable subscriptions to the topic.

After creating the durable subscription, the client may return to consume the messages later (may be daily, weekly, monthly, etc).

Since the clients are not always online, message consumption is by TopicSubscriber.receive() function (NOT by message listeners)

The issue we encounter is when a subscription has many expired (TTL'ed) messages.

JBoss Messaging only gets rid of expired messages "on-the-fly" when the TopicSubscriber.receive() is called. It can take non-trival minutes to get to the first non-expired message if the subscription contains many expired messages.

We currently uses TopicSubscriber.receive(5000), which means if JBoss Messaging cannot get to the 1st non-expired message within 5 seconds, it returns null (no message).

To "worsen" the problem, message consumption is via a RPC-style facade function and will most likely timed out.

Is there anyway to configure JBoss Messaging to delete expired message actively via perhaps some kind of cron job?

Or any other suggestions?

Thank you.


p.s. The topic is deployed in a cluster. We have thought of using a nightly cron job to receive() using CLIENT_ACKNOWLEDGE and rollback to get rid of the expired messages... but we cannot find a way to reliably get to the specific connection managers of each node within the cluster. (i.e. we may get the connection manager of cluster A even though we point the jndi url to cluster B.)

[gaohoward]

If you deploy the topic as a clustered topic, you don't need to worry about the connection to a specific node in the cluster.

[chacs]

In a clustered environment, the subscriptions are also split into sub-subscriptions at each cluster. If we wish to implement the nightly cron to clear the expired messages (using CLIENT_ACKNOWLEDGE and rollback), we must be able to obtain the connection manager for each cluster to clear it's local expired messages. The inability to connect to a specific cluster means this cannot be a viable solution.

[gaohoward]

It should not be necessary for a subscriber to connect to each node in order to receive all of its messages. In JBM if message sucker is configured, you can receive messages from any node in the cluster. The user guide provides detailed info about it.

Howard