[
https://issues.apache.org/jira/browse/QPID-2935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12930163#action_12930163
]
Ken Giusti commented on QPID-2935:
----------------------------------
A high-level description of a proposed solution:
*) Use credit to prevent queue overflow event.
*) Associate watermarks with each Queue instance. Each queue would maintain a
high and low watermark corresponding to a capacity level within the queue - the
number of queued messages, for example, or the total number of message bytes
enqueued. The watermarks would be constrained such that high_watermark >=
low_watermark: the high_watermark would indicate the level of capacity at and
above which the queue is considered likely to overflow. The low_watermark
would indicate the level at or below which the queue is no longer considered
likely to overflow.
*) Associate a state with each Queue instance that reflects the current level
of data in the queue with respect to the watermarks. When the current level
of data in the queue crosses the high_watermark, the state is set to
"blocking". When the current level of data in the queue falls below the
low_watermark, the state will transition to "normal" from "blocking"
*) Each message transferred to the broker will maintain a boolean "blocked"
flag. After a message has been enqueued to all of the destination queues, the
block flag will be set if one or more of the destination queues are in the
blocking state.
*) The transfer of any message which has a set "blocked" flag will not be
completed from the point of view of the client until the flag is reset.
*) A message's "blocked" flag will be reset when: 1) the state of all
destination queues become "normal" or 2) the message is consumed from all
queues.
*) The message is completed once the "blocked" flag is reset.
Issues with this approach:
1) the capacity level configured for a given producer must take into account
the high_watermark setting of the potential destination queues. If the
producer's capacity level is too high for a given queue (or the sum of all
potential producer's capacity), the queue will overflow regardless of this
solution.
2) A producer will be blocked based on the destination of the current set of
outbound messages. A pending transfer of a message to a different - possibly
unblocked - destination would be blocked by the current outstanding messages.
This appears to be unavoidable given the 0.10 model.
> 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-subscr...@qpid.apache.org
