You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by "Gao, Jie (Kyrie, HPIT-DS-CDC)" <ji...@hp.com> on 2014/10/29 12:56:48 UTC
flow control in Broker Federation on 0.22
Hello Qpid experts,
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?
By the way, the version of the qpidd I use is 0.22 and the client uses qpid messaging.
Thanks,
Kyrie
Re: flow control in Broker Federation on 0.22
Posted by Gordon Sim <gs...@redhat.com>.
On 11/27/2014 03:09 PM, Kyrie.Gao wrote:
> Thank you Gordon! We have decided to apply setCapacity feature into our
> project, however, the way to success is always so tortuous. It seems that
> there are two set of client apis (qpid.messaging and qpid.client) and the
> way to use them are totally different. It seems that qpid.client is more
> strict to AMQP protocol?
The qpid::client API is quite tightly tied to the 0-10 version of AMQP.
It is a deprecated API and I would strongly advise against using it. In
fact it has been removed from the public interfaces in more recent releases.
> I can do the following steps to set its capacity by using qpid.messsaging.
>
> /Session session = connection.createSession();
> Sender sender = session.createSender(address);
> sender.setCapacity(n);/
>
> However, I cannot find out how to set capacity by using qpid.client. What I
> found in some docs about how to use it is all about the basic connection and
> sending messaging.
>
> /Session session = connection.newSession();
> // session.createSender("amq.topic"); // compilation error for session class
> has no such interface.
> session.messageTransfer(arg::content=message, arg::destination="amq.topic");
> /
>
>
> Instead using sender, it just uses session to send out the messages. At this
> time, I notice some interfaces that are related to flow control.
The 0-10 flow control is used by receivers to limit how many messages
they can be sent. qpidd will not use this mechanism to flow control senders.
The capacity of a sender is essentially the number of in-doubt messages.
That is one of the benefits of using the qpid::messaging interface
instead of qpid::client, its simpler yet provides richer functionality.
> /session.messageStop(arg::destination="amq.topic");
> session.messageSetFlowMode(arg::destination="amq.topic", arg::flowMode=1,
> arg::sync=false);/
>
> But the program throws an exception like "cannot find destination".
Yes, the broker cannot find a destination for outgoing messages -
messages sent *by* the broker *to* the client - which is what the flow
control methods above would operate on.
> Now I
> have no idea about how to apply flow control in qpid.client. Maybe they are
> not supported at all?
>
> I await your prompt response.
>
> Thanks,
> Kyrie
>
>
>
> --
> View this message in context: http://qpid.2158936.n2.nabble.com/flow-control-in-Broker-Federation-on-0-22-tp7615885p7616894.html
> Sent from the Apache Qpid users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: flow control in Broker Federation on 0.22
Posted by "Kyrie.Gao" <ji...@hp.com>.
Thank you Gordon! We have decided to apply setCapacity feature into our
project, however, the way to success is always so tortuous. It seems that
there are two set of client apis (qpid.messaging and qpid.client) and the
way to use them are totally different. It seems that qpid.client is more
strict to AMQP protocol?
I can do the following steps to set its capacity by using qpid.messsaging.
/Session session = connection.createSession();
Sender sender = session.createSender(address);
sender.setCapacity(n);/
However, I cannot find out how to set capacity by using qpid.client. What I
found in some docs about how to use it is all about the basic connection and
sending messaging.
/Session session = connection.newSession();
// session.createSender("amq.topic"); // compilation error for session class
has no such interface.
session.messageTransfer(arg::content=message, arg::destination="amq.topic");
/
Instead using sender, it just uses session to send out the messages. At this
time, I notice some interfaces that are related to flow control.
/session.messageStop(arg::destination="amq.topic");
session.messageSetFlowMode(arg::destination="amq.topic", arg::flowMode=1,
arg::sync=false);/
But the program throws an exception like "cannot find destination". Now I
have no idea about how to apply flow control in qpid.client. Maybe they are
not supported at all?
I await your prompt response.
Thanks,
Kyrie
--
View this message in context: http://qpid.2158936.n2.nabble.com/flow-control-in-Broker-Federation-on-0-22-tp7615885p7616894.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: flow control in Broker Federation on 0.22
Posted by Gordon Sim <gs...@redhat.com>.
On 11/20/2014 03:11 AM, Kyrie.Gao wrote:
> Hello Gordon,
>
> Just one more thing. I have tried to set capacity and sent messages by using
> C++, and the result is quite positive. While I use python client to do the
> same thing, it sounds that setCapacity is useless at all. Is it a
> malfunction with regard to qpid python Sender class?
>
> By the way, I sent 10k messages to broker at once. First time I modify the
> capacity to 1 and second time I set the value to 1000. Both of these two
> experiments cost about 10s. I tried with both version 0.14 and 0.30. I also
> read the source code, I mean qpid:messaging:endpoints.py, the Sender class
> shows me that it will wait for a few million-seconds when the available
> value comes to 0, but this value is never down to 0.
By default the send in the python qpid.messaging client is synchronous -
i.e. it will block until confirmed by the broker. In this mode, the
capacity is of little value as you say.
However yo can specify sync=False as a parameter to send(), in which
case it will be asynchronous and the capacity will be used as with the
default in the c++ qpid::messaging client.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: flow control in Broker Federation on 0.22
Posted by "Kyrie.Gao" <ji...@hp.com>.
Hello Gordon,
Just one more thing. I have tried to set capacity and sent messages by using
C++, and the result is quite positive. While I use python client to do the
same thing, it sounds that setCapacity is useless at all. Is it a
malfunction with regard to qpid python Sender class?
By the way, I sent 10k messages to broker at once. First time I modify the
capacity to 1 and second time I set the value to 1000. Both of these two
experiments cost about 10s. I tried with both version 0.14 and 0.30. I also
read the source code, I mean qpid:messaging:endpoints.py, the Sender class
shows me that it will wait for a few million-seconds when the available
value comes to 0, but this value is never down to 0.
Thanks,
Kyrie
--
View this message in context: http://qpid.2158936.n2.nabble.com/flow-control-in-Broker-Federation-on-0-22-tp7615885p7616610.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: flow control in Broker Federation on 0.22
Posted by Gordon Sim <gs...@redhat.com>.
On 11/12/2014 10:08 AM, Kyrie.Gao wrote:
> Hello Gordon,
>
> I did some experiments based on your suggestions, and the results sound that
> some of the option you mentioned doesn't have any effect. Uhmm...I am not
> sure if my test steps are right.
>
> /* To enable flow control over a federation link, you need to use the
> --ack option/
>
> The help page tells us its meaning “Acknowledge transfers over the bridge in
> batches of N”. When I set ack to a very huge value like 63537 and then set
> back to 10, no special things happen. May be it should be used on a queue
> route?
Yes, it appears that support for flow control with other routes did not
get added until Qpid 0.24, so for 0.22 exchange links the --ack option
would have no effect.
> ps: we use a static exchange route currently. a queue route cannot be used
> in our project because changing to it costs too much effort.
>
> /* 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/
>
> I set a lower value for the capacity, say, from 50 to 1, and it has some
> effects on sending speed. It will need more time to send out all of the
> messages with the new value than the previous one, in another point of view,
> it can ease the broker’s pressure and reduce the possibility of the flood
> event issue. But by this way we cannot solve the problem thoroughly. In
> addition, by this way (change something by client side) we need to ask
> people from other team to do some fix.
Fair enough. Clients that send more messages than the queue can cope
with will get an exception.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: flow control in Broker Federation on 0.22
Posted by "Kyrie.Gao" <ji...@hp.com>.
Hello Gordon,
I did some experiments based on your suggestions, and the results sound that
some of the option you mentioned doesn't have any effect. Uhmm...I am not
sure if my test steps are right.
/* To enable flow control over a federation link, you need to use the
--ack option/
The help page tells us its meaning “Acknowledge transfers over the bridge in
batches of N”. When I set ack to a very huge value like 63537 and then set
back to 10, no special things happen. May be it should be used on a queue
route?
ps: we use a static exchange route currently. a queue route cannot be used
in our project because changing to it costs too much effort.
/* 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/
I set a lower value for the capacity, say, from 50 to 1, and it has some
effects on sending speed. It will need more time to send out all of the
messages with the new value than the previous one, in another point of view,
it can ease the broker’s pressure and reduce the possibility of the flood
event issue. But by this way we cannot solve the problem thoroughly. In
addition, by this way (change something by client side) we need to ask
people from other team to do some fix.
/* 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./
it costs too much effort if we gonna to use queue route.
Thanks,
Kyrie
Gordon Sim wrote
> 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:
> users-unsubscribe@.apache
> For additional commands, e-mail:
> users-help@.apache
--
View this message in context: http://qpid.2158936.n2.nabble.com/flow-control-in-Broker-Federation-on-0-22-tp7615885p7616308.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: flow control in Broker Federation on 0.22
Posted by Gordon Sim <gs...@redhat.com>.
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: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org