qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: [jira] Created: (QPID-36) Add high and low watermark to flow control
Date Mon, 16 Oct 2006 14:54:15 GMT
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.


Mime
View raw message