We ran into a similar problem with one of our ActiveMQ implementations. My theory was that messages were being paged out of memory and the consumers were consuming faster than the dispatch queue could be re-filled. We made a plethora of changes all at once, but here was the tact I took:
1. Faster datastore (switch from journaled JDBC/Derby to AMQ Message Store) 2. Switch from store-based cursors to file-based cursors (if we were for some reason married to the JDBC datastore) 3. Increase the size of the dispatch queue, forcing a larger "store fetch" (default is 200 msgs): <policyEntry queue=">" maxPageSize="5000"/> 4. Increase the heap and memoryUsage limits to allow for more memory <memoryUsage limit="3 gb" /> Since by default AMQ uses store-based cursors for persistent messages and only uses a special file-based cursor for non-persistent messages, a slow datastore could be your problem. Non-persistent message never hit the datastore, so the would not be affected. Best of luck, curious if this addresses your problem. On 1/30/09 6:02 PM, "Jim Gomes" <e.se...@gmail.com> wrote: > This seems very similar to a problem we are > experiencing with the broker halting dispatch of messages to consumers that > are ready and able to receive messages. --- Bill Schuller, Service Foundations Engineering, Intuit Inc.
