Description

If you have a JMS producer sending messages to multiple consumers and you have the cacheLevel set to 3 or higher, eventually all consumers will run as slow as the slowest consumer.
In the attached projects the SA sends messages to a MockOptimizer (JMS consumer) that has two threads. One sleeps for one second and the other sleeps for ten. Initially the thread sleeping for 1 second will consume most of the messages, but towards the end it will start to consume messages every ten seconds as well.

The issue revolves around how ActiveMQ 5.x pages and dispatches messages to consumers. Every queue keeps list of paged in messages which defaults to 100 max entires. It round robins dispatching messages between consumers, even the slow consumers. Once the slow consumer gets 100 dispatched messages which it has not yet acked due to it being slow, then no further messages are paged in since the page in list is full.

I am evaluating different ways to implement this but, any change to this code could have repercussions which need to get evaluated.

Hiram Chirino
added a comment - 25/Jul/08 7:18 AM The issue revolves around how ActiveMQ 5.x pages and dispatches messages to consumers. Every queue keeps list of paged in messages which defaults to 100 max entires. It round robins dispatching messages between consumers, even the slow consumers. Once the slow consumer gets 100 dispatched messages which it has not yet acked due to it being slow, then no further messages are paged in since the page in list is full.
I am evaluating different ways to implement this but, any change to this code could have repercussions which need to get evaluated.

https://issues.apache.org/activemq/browse/AMQ-1866 has the latest updates. In short we are still looking for an optimal fix for this. Already two different fix proposoals have been made but were found lacking. We still continuing to to work on the problem.

Hiram Chirino
added a comment - 29/Jul/08 8:50 AM https://issues.apache.org/activemq/browse/AMQ-1866 has the latest updates. In short we are still looking for an optimal fix for this. Already two different fix proposoals have been made but were found lacking. We still continuing to to work on the problem.

Hiram Chirino
added a comment - 07/Aug/08 11:12 AM Update.. we are now currently evaluating and testing the attached patch. It fixes the slow producer problem but we are trying to verify that it as not caused any other regressions.