@dan, Are you using persistent messages? If yes, typically dispatching is faster than persisting messages and when the consumers are fast we can by pass storing and syncing to disk if the consumer acks before the disk write has started. As a result, through put can be very high.
When we persist, the producer typically waits for the disk sync. Using alwaysSendAsync=true avoids that. You should use the default store cursor, which will just stop caching messages when its memory limit is reached. Note, that producer flow control false does not stop memory limits, it just moves the wait to the broker rather than the producer (client) so watch out for log messages that indicate a producer is waiting for space. If you are using non persistent messages, ensure that the temp store limit is not being reached. On 15 April 2011 07:13, dcheckoway <dchecko...@gmail.com> wrote: > I'm looking for help "decoupling" producers from consumers. In a nutshell, > this is my setup: > > producer --> embedded broker > > embedded broker --> (camel route) --> external broker > > external broker --> consumer > > As of right now, if I shut down the consumer, the queue in the external > broker grows -- that's fully expected. But what's unexpected is that > everything upstream slows down, and I end up with a queue backlog in the > embedded broker. I have producerFlowControl="false" across the board. I'm > having trouble understanding why this upstream throttling and backlog is > happening. > > My goal is...if the consumer is the only piece that's down (or slow), I > still want messages to flow at full speed all the way to the external > broker, where they're welcome to queue up. I don't want anything producer > flow controlled...ever. > > Is this possible with ActiveMQ? > > ----- > Dan Checkoway > dcheckoway gmail com > -- > View this message in context: > http://activemq.2283324.n4.nabble.com/Upstream-throttling-and-backlog-tp3451330p3451330.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com. > -- http://fusesource.com http://blog.garytully.com
