Martin Ritchie (JIRA) wrote:
Add high and low watermark to flow control ------------------------------------------Key: QPID-36 URL: http://issues.apache.org/jira/browse/QPID-36 Project: Qpid Issue Type: Improvement Components: Java Broker, Java Client Reporter: Martin Ritchie Assigned To: Martin Ritchie Currently the flow control is regulated by the prefetch count. This needs to be improved to prevent the channel from thrashing at the limit. AMQP changes will affect the initialisation of these values so - Start with implementing the broker changes. - Work on protocol changes once they have been agreed.
Could this not be done on the client? What changes are you planning to the broker?
There are two separate ways in which the flow of messages to a consumer can be stopped on the broker. The first is through the use of the channel.flow request. The second is, as stated above, through setting a prefetch limit on the channel and is relevant only when acknowledgements are used.
If delivery is suspended due to the number of outstanding, unacknowldeged messages reaching the set prefetch limit, it is enabled when one or more acknowledgements are received.
On the other hand, when delivery is suspended through the first method, it is enabled again by sending another channel.flow request turning delivery back on. Currently, when no acknowledgements are used, the java client relies on the FlowControllingBlockingQueue to enable/disable delivery through control.flow requests. (The clients prefetch is also used in regulating this, but it is reusing that value rather than actually implementing a prefetch).
FlowControllingBlockingQueue uses a crude test that will result in blocking and unblocking the flow rather too regularly. I suspect that this may be the cause of the 'thrashing' you refer to and a high/low watermark approach here would certainly make sense.
