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 <[email protected]> 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 > > -- http://blog.garytully.com http://fusesource.com
