On 10/29/2014 11:56 AM, Gao, Jie (Kyrie, HPIT-DS-CDC) wrote:
Currently we want to use flow control feature in our project for one of the
client program produced too many events in a short time, or called event flood.
Messages which may be very vital for the customers will be lost so we want to
find a way to slow down incoming publications. Then we noticed the flow
control, it seems that the client will throttle itself per qpid doc:
http://qpid.apache.org/releases/qpid-0.30/cpp-broker/book/producer-flow-control.html.
However, after I did more experiments on this, the result seems to be tricky.
Assume there is only one broker and one normal queue that I add by using
qpid-config, everything behaviors just like what that qpid doc told us. At this
time client(producer) will be blocked when this normal queue is up to the
bottle neck. When I add one more broker and create an exchange route between
them, it seems to be more complex with regard to flow control issue.
Broker A(bridge_queue_a) ------Broker B (queue_b, bridge)
Suppose broker B has a normal queue named “queue_b” (limited by 100 bytes and
flow stop threshold is 50 bytes) and broker A has a bridge queue named
“bridge_queue_a”(also limited by 100 bytes). Using a client called “c” to send
out some messages (10 bytes each), we can see queue_b will set the flow stop
flag as true after 5 messages are sent from client c. when we want to send
another 5 messages, client c will throw an warning exception thus the process
will exit abnormally. Intriguingly, bridge_queue_a is deleted in a heartbeat
and soon after that create a new one, so bridge_queue_a will never meet flow
stop problem. It seems a defeat, from our standpoint.
So my question is, does it considered as a normal behavior? Or does I make any
mistake /misunderstanding from that?
A couple of different points that may (or may not!) help:
* To enable flow control over a federation link, you need to use the
--ack option
* flow control in the client is tied to the sender capacity. The back
pressure by the broker is in the form of delayed acknowledgement of
published messages and the number of outstanding unacknowledged
published messages on a sender is giverned by the capacity So for a low
limit, you want to lower the capacity of the sender
* if you don't need the route to be an exchange route, you can make it a
queue route which doesn't involve the automatic creation of a bridge
queue. along with the ack option this should prevent messages being lost
over the federation link.
Hope this helps (and sorry for the delayed response),
--Gordon.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
