activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Tully <>
Subject Re: Message Cursors and Dispatch
Date Tue, 08 Mar 2011 12:34:55 GMT
That is expected for the file based cursor. It tries to proxy the
store, so the entire store is replayed through the cursor to ensure
correct message order. This behavoour only makes sense if the
underlying store is very slow, which in your case, kahaDB, is not.

The store based cursor will be a better match a it does not attempt to
proxy the whole store, rather it reads it in batches and only starts
to cursor new messages in memory when the store is exhausted.

On 8 March 2011 02:06, Anirudha Khanna <> wrote:
> Hi,
> So I added a custom subscription recovery policy to ActiveMQ-5.3.2 that stores messages
in a different instance of Kaha Db. To load test this recovery policy we sent close to ~ 82
million messages(24 hours worth of messages) to the topic that has the recovery policy enabled
on it.
> When connecting a single consumer after broker restart, I noticed that the consumer takes
a long time to even start getting the messages. Looking at the stack trace it seems that ActiveMQ
first attempts to add all the recovered messages to a Message Cursor(in this case a File Message
cursor) and only then start the dispatch(the dispatch thread is WAITING). Before restarting
the broker a single consumer was able to receive messages fairly quickly.
> Is this the expected behaviour for ActiveMQ, that ALL messages will first be added to
the Message cursor before they are dispatched? Is there a way to get around this?
> Thanks,
> Anirudha


View raw message