Hi Bill, Thanks for the tips and suggestions. I'll take a look at giving them a try. Right now our data store is the default Kaha data store. I had wondered if switching to some other data store might improve things.
- Jim On Thu, Feb 5, 2009 at 4:41 AM, Bill Schuller <bill_schul...@intuit.com>wrote: > 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. > >
