[
https://issues.apache.org/jira/browse/QPID-942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12755961#action_12755961
]
Rob Godfrey commented on QPID-942:
----------------------------------
I am working on a patch to implement channel level flow control in the AMQP
0-8/0-9 codepath of the Java Broker... The general approach will be along the
lines of point 2. in the description of the JIRA("[Flow control is triggered
when] A client attempting to publish to a queue that is beyond its max-depth.
"). Extension to also address approach 1. can be added at a later point
without great difficulty.
The approach uses new configuration parameters to set a size (in bytes) at
which a queue will start blocking publishers... and a second (smaller) size at
which the queue will unblock publishers which have previously been blocked.
Due to the lack of synchronous publish in 0-8/0-9 the queue may grow beyond the
maximum size before the client is successfully flow controlled.
> Introduce client flow control and broker overflow protection
> ------------------------------------------------------------
>
> Key: QPID-942
> URL: https://issues.apache.org/jira/browse/QPID-942
> Project: Qpid
> Issue Type: New Feature
> Components: Java Broker, Java Client
> Reporter: Marnie McCormack
> Assignee: Rob Godfrey
> Fix For: 0.6
>
>
> Certainly the Java, and probably the other clients do not obey flow-control
> commands from the broker. The Java broker never sends them to clients either.
> This is in the 0-8 spec. so not fully AMQP compliant without it.
> Client Work
> -------------------
> Flow control to be implemented in clients. The clients must also have buffer
> limiting in place prior to this, or flow-controlling a client will only shift
> OOMEs from the broker to the clients. Bounded buffers plus back-pressure from
> the broker will should ultimately lead to the 'send' method blocking once the
> system as a whole is completely saturated. This may mean that the broker gets
> a needed opportunity to chew its way through the back-log, resulting in
> healthy throughputs under saturation.
> Broker Work
> ------------------
> A strategy for deciding when to flow control clients from the broker needs to
> be decided upon. Flow-control has per-connection granularity, which makes
> deciding when to do it on a per route basis awkward. Flow-control may be
> triggered by:
> 1. The broker being low on memory globally across the message store and all
> queues.
> 2. A client attempting to publish to a queue that is beyond its max-depth.
> 3. Based on history of destinations a client usually publishes to (or has
> published to), flow-control client if one of them is beyond max-depth.
> A well-conditioned application will not experience 'send' blocking, except
> under exceptional loads, whereupon it will act as a safety valve to prevent
> either clients or broker from throwing OOME. The other scenario that may
> cause back-logs, is slow consumers without TTL.
> No time estimate for this yet, as its a fairly large piece of work, and not
> yet decided exactly how its to be done. Need a design proposal before
> starting work, to be reviewed by the qpid-dev group.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
