qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marnie McCormack (JIRA)" <qpid-...@incubator.apache.org>
Subject [jira] Updated: (QPID-942) Introduce client flow control and broker overflow protection
Date Mon, 14 Dec 2009 20:31:26 GMT

     [ https://issues.apache.org/jira/browse/QPID-942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Marnie McCormack updated QPID-942:
----------------------------------

    Fix Version/s:     (was: 0.6)
                   0.7

Moving items unlikely to be completed for 0.6 out to 0.7

> 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.7
>
>
> 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-subscribe@qpid.apache.org


Mime
View raw message