On 16/10/06, Gordon Sim <[EMAIL PROTECTED]> wrote:
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.



The changes I was planning were not great simply as you say to prevent
the suspend/unsuspending of the channel occurring too regularly when
using acknowledgements (Broker controlled flow control). The second
part of the change would be to allow the client to specify the ratio
between the two levels. This of course isn't possible with the current
AMQP but I don't know the full nature of the upcoming changes so
perhaps it will be cleared up.

--
Martin Ritchie

Reply via email to