You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Alan Conway (JIRA)" <ji...@apache.org> on 2010/11/17 22:09:14 UTC

[jira] Issue Comment Edited: (QPID-2935) Support "best effort" producer flow control within the AMQP 0.10 implementation.

    [ https://issues.apache.org/jira/browse/QPID-2935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12933163#action_12933163 ] 

Alan Conway edited comment on QPID-2935 at 11/17/10 4:09 PM:
-------------------------------------------------------------

This will affect the cluster. 

- All new queue state (watermarks and blocking flags) will need to be passed in update to new brokers joining
- Introduces a new timer task, this will have to  use the cluster timer in a cluster, or some other solution to ensure actions are synchronized across the cluster

The appropriate changes to the cluster need to be comitted along with the flow control solution, othewise cluster brokers will become inconsistent and crash sporadically with invalid-arg errors.


      was (Author: aconway):
    This will affect the cluster. The watermarks and blocking flags will need to be passed to new brokers joining the cluster, otherwise queues will become inconsistent and brokers will shut down. The appropriate changes to the cluster should be comitted along with the flow control solution.

  
> Support "best effort" producer flow control within the AMQP 0.10 implementation.
> --------------------------------------------------------------------------------
>
>                 Key: QPID-2935
>                 URL: https://issues.apache.org/jira/browse/QPID-2935
>             Project: Qpid
>          Issue Type: New Feature
>          Components: C++ Broker, C++ Client
>    Affects Versions: 0.9
>         Environment: any
>            Reporter: Ken Giusti
>            Assignee: Ken Giusti
>             Fix For: Future
>
>         Attachments: QPID-2935.tgz
>
>
> To what extent, if any, could producer flow control be supported on the existing (pre-1.0) protocol?
> In the current C++ broker/client implementation, when a queue on the broker fills to the point where it cannot accept any more messages (--default-queue-limit hit), the broker will forcibly disconnect any client that attempts to route a message to that queue.   This is an abrupt failure - the producing client is not privy to the queue's remaining capacity.  The broker provides no feedback to the producing client, which could be used to throttle the client's message production rate.
> The purpose of this JIRA is to explore the possible methods for implementing producer throttling on the current 0.10 C++ codebase. 

-- 
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