Question

I am using ActiveMQ 5.4 with KahaDB as message store.
While Publishing Messages (with Persistence true) to a Topic, which has Durable subscriber, the persistence store is increasing even the messages are dispatched to Subscriber. So this is causing an issue as the message store is getting full and not accepting any more messages.

So my question is why the Persistence store is not discarding the messages in the KahaDB, even the messages are getting dispatched?

Regards,

Srinivas

Answer 1

What you are seeing is an interaction between the ActiveMQ message store behaviour and that for durable subscriptions on topics.

When you have durable subscriptions, a topic is treated like a queue for each subscriber’s clientId (set on the Connection). The logic being that the client doesn’t want to miss any messages when they disconnect. So if they disconnect, the durable subscription hangs around and keeps the messages alive.

The AMQ message store uses data logs for it’s message journal. These are written sequentially, and never actually removed from (that would require random access). There is a second file which keeps track of which messages have been consumed. Once all the messages in a data file have been consumed, that file is deleted.

So what you’re seeing is that some of the messages in the data file are not being consumed by these durable subscriptions and just hang around. ClientIds for durable subscribers not being consistently used would cause this issue. It’s likely that there is something wrong with the way the feature is being used, if you use JMX to inspect the subscriptions on the broker that should help you track down the root cause.

As a general rule, whenever you think that you might want to use a durable subscription, use virtual topics instead – they are much easier to reason about, inspect and load balance. On the other hand if you just want to get the last couple of messages when you reconnect a topic subscriber rather than all the messages you may have missed, use retroactive consumers.

An easy way to get around this issue is to always use a time to live when you send a message – pretty much every use case has a time limit of when a message ought to be consumed by anyway. ActiveMQ will expire messages beyond this point, and free up the messages in the data files for deletion.