qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Ritchie" <ritch...@apache.org>
Subject Re: [jira] Created: (QPID-36) Add high and low watermark to flow control
Date Mon, 16 Oct 2006 15:25:25 GMT
On 16/10/06, Gordon Sim <gsim@redhat.com> 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

View raw message