You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Haoliang Chen <ch...@gmail.com> on 2015/07/22 11:33:34 UTC
0.30 C++ Broker: MsgDrop in topic exchanges' dynamic route
Hello all,
I was attempting to establish a reliable route between two exchanges on two
brokers, but
failed. It seem like the packages start to be dropped by the source broker
once its buffer
was full. I want the source broker stop to recive if its buffer was full.
I have a federation consist of two 0.30 brokers on different computers,
donate by B1 and B2.
Both run on the same config,
auth=no
realm=QPID
data-dir=/home/MQ/broker-data/
And I new a exchange on both brokers using the following command:
qpid-config -b B1 add exchange topic My.topic --durable
qpid-config -b B2 add exchange topic My.topic --durable
Then I add route:
qpid-route -d --ack=10 dynamic add B1 B2 My.topic
qpid-route -d --ack=10 dynamic add B2 B1 My.topic
Then I start to recived from B1 with the 0.32 qpid-recieve on Windows:
qpid-receive -b B1 -a My.topic --verify-sequence --print-content 0
--timeout 100
--report-every 100000
And I start to flood B2 with the 0.32 qpid-send on Windows:
qpid-send -b B2 -a My.topic -m 0 --durable yes --content-size 10240
--report-every 100000
Not long after, the qpid-receive stop and I Got:
qpid-receive: Gap in sequence numbers 18987-19742
(..\..\..\qpid-cpp-0.32\src\te
sts\qpid-receive.cpp:172)
Meanwhile the qpid-send keep running and sending. The Task Manager shown a
static outgoing
rate.
Here are the output of #qpid-stat -e -b B1
Exchanges
exchange type dur bind msgIn msgOut msgDrop byteIn
byteOut byteDrop
===========================================================================================
direct 2 0 0 0 0
0 0
My.topic topic Y 0 110k 29.8k 81.1k 1.14g
307m 835m
...
Here are the output of #qpid-stat -e -b B2
Exchanges
exchange type dur bind msgIn msgOut msgDrop byteIn
byteOut byteDrop
===========================================================================================
direct 2 0 0 0 0
0 0
My.topic topic Y 0 29.6k 29.6k 0 306m
306m 0
...
And the network info:
WindowsClient to B1/B2 is faster than B1/B2 to WindowsClient;
B1/B2 is connected to the same switch.
If I send to and receive form the same broker, it works well. No msg was
lost, very reliable.
Incomming message will be rejected or jammed once the broker's buffer was
full. The Task
Maneger shown pauses on outgoing rate.
I want the federation behave like that, jam the sender once the broker's
buffer was full and
don't drop any message. What did I miss?
Sorry for the english, I am not a native english speaker.
Harris
Re: 0.30 C++ Broker: MsgDrop in topic exchanges' dynamic route
Posted by Gordon Sim <gs...@redhat.com>.
On 08/13/2015 07:50 AM, Haoliang Chen wrote:
> So how can I ensure the message was transfer within the federation
> successfully?
>
> Simply put, the problem is if one broker was jammed by a slow receiver,
> messages will be dropped between the source broker and the jammed broker
> silently.
If you want to buffer messages for another broker while no connection
exists to that broker, then you need to use queue routes (and explicitly
configure your queue to manage any anticipated build up). If a large
amount of backlog may need to be stored, the paged queue may be of
interest (it keeps the messages on disk, only swapping a small portion
into memory at any time as needed).
Federation in qpidd is tied to a store-and-forward pattern. There is no
end-to-end acknowledgement.
Depedning on your use case you may also want to consider qpid dispatch
router, which is a much more sophisticated approach to creating networks
of 'message forwarders' and gives end-to-end acknowledgement as well as
redundant routes for better fault tolerance.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: 0.30 C++ Broker: MsgDrop in topic exchanges' dynamic route
Posted by Haoliang Chen <ch...@gmail.com>.
So how can I ensure the message was transfer within the federation
successfully?
Simply put, the problem is if one broker was jammed by a slow receiver,
messages will be dropped between the source broker and the jammed broker
silently.
2015-07-28 4:14 GMT+08:00 Gordon Sim <gs...@redhat.com>:
> On 07/24/2015 04:25 AM, Haoliang Chen wrote:
>
>> After further investigation, I found the "--ack=10" parameter hasn't pass
>> to the subscription.
>>
>> qpid: show 126
>> Attribute 126
>> =========================
>> sessionRef 124
>> queueRef 118
>> name My.topic
>> browsing False
>> acknowledged False
>> exclusive True
>> creditMode WINDOW
>> arguments {}
>> delivered 2000
>>
>> But if "--ack=10" was apply to a queue route, the "acknowledged" row will
>> be "True".
>>
>
> The acknowledged transfer option is only applicable to queue routes at
> present because exchange routes use temporary queues that are deleted when
> disconnected.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: 0.30 C++ Broker: MsgDrop in topic exchanges' dynamic route
Posted by Gordon Sim <gs...@redhat.com>.
On 07/24/2015 04:25 AM, Haoliang Chen wrote:
> After further investigation, I found the "--ack=10" parameter hasn't pass
> to the subscription.
>
> qpid: show 126
> Attribute 126
> =========================
> sessionRef 124
> queueRef 118
> name My.topic
> browsing False
> acknowledged False
> exclusive True
> creditMode WINDOW
> arguments {}
> delivered 2000
>
> But if "--ack=10" was apply to a queue route, the "acknowledged" row will
> be "True".
The acknowledged transfer option is only applicable to queue routes at
present because exchange routes use temporary queues that are deleted
when disconnected.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: 0.30 C++ Broker: MsgDrop in topic exchanges' dynamic route
Posted by Haoliang Chen <ch...@gmail.com>.
After further investigation, I found the "--ack=10" parameter hasn't pass
to the subscription.
qpid: show 126
Attribute 126
=========================
sessionRef 124
queueRef 118
name My.topic
browsing False
acknowledged False
exclusive True
creditMode WINDOW
arguments {}
delivered 2000
But if "--ack=10" was apply to a queue route, the "acknowledged" row will
be "True".
2015-07-23 14:36 GMT+08:00 Haoliang Chen <ch...@gmail.com>:
> The result is easier to reproduce if the dest broker was
> set --default-queue-limit 10240.
>
> And the dest broker will throw:
> 2015-07-23 14:31:43 [Broker] warning Exchange My.topic cannot deliver to
> queue My.topic_284ad1f5-b871-4c13-9a59-f1d6319b8286:
> resource-limit-exceeded: Maximum depth exceeded
> on My.topic_284ad1f5-b871-4c13-9a59-f1d6319b8286: current=[count: 8, size:
> 9152], max=[size: 10240]
> (/home/MQ/qpid-cpp-0.32/src/qpid/broker/Queue.cpp:1628)
>
> As you see, this problem also happened on 0.32 Brokers.
>
> 2015-07-22 17:33 GMT+08:00 Haoliang Chen <ch...@gmail.com>:
>
>> Hello all,
>>
>> I was attempting to establish a reliable route between two exchanges on
>> two brokers, but
>> failed. It seem like the packages start to be dropped by the source
>> broker once its buffer
>> was full. I want the source broker stop to recive if its buffer was full.
>>
>> I have a federation consist of two 0.30 brokers on different computers,
>> donate by B1 and B2.
>> Both run on the same config,
>>
>> auth=no
>> realm=QPID
>> data-dir=/home/MQ/broker-data/
>>
>> And I new a exchange on both brokers using the following command:
>> qpid-config -b B1 add exchange topic My.topic --durable
>> qpid-config -b B2 add exchange topic My.topic --durable
>>
>> Then I add route:
>> qpid-route -d --ack=10 dynamic add B1 B2 My.topic
>> qpid-route -d --ack=10 dynamic add B2 B1 My.topic
>>
>> Then I start to recived from B1 with the 0.32 qpid-recieve on Windows:
>> qpid-receive -b B1 -a My.topic --verify-sequence --print-content 0
>> --timeout 100
>> --report-every 100000
>>
>> And I start to flood B2 with the 0.32 qpid-send on Windows:
>> qpid-send -b B2 -a My.topic -m 0 --durable yes --content-size 10240
>> --report-every 100000
>>
>> Not long after, the qpid-receive stop and I Got:
>> qpid-receive: Gap in sequence numbers 18987-19742
>> (..\..\..\qpid-cpp-0.32\src\te
>> sts\qpid-receive.cpp:172)
>>
>> Meanwhile the qpid-send keep running and sending. The Task Manager shown
>> a static outgoing
>> rate.
>>
>> Here are the output of #qpid-stat -e -b B1
>> Exchanges
>> exchange type dur bind msgIn msgOut msgDrop byteIn
>> byteOut byteDrop
>>
>> ===========================================================================================
>> direct 2 0 0 0 0
>> 0 0
>> My.topic topic Y 0 110k 29.8k 81.1k 1.14g
>> 307m 835m
>> ...
>>
>> Here are the output of #qpid-stat -e -b B2
>> Exchanges
>> exchange type dur bind msgIn msgOut msgDrop byteIn
>> byteOut byteDrop
>>
>> ===========================================================================================
>> direct 2 0 0 0 0
>> 0 0
>> My.topic topic Y 0 29.6k 29.6k 0 306m
>> 306m 0
>> ...
>>
>> And the network info:
>> WindowsClient to B1/B2 is faster than B1/B2 to WindowsClient;
>> B1/B2 is connected to the same switch.
>>
>> If I send to and receive form the same broker, it works well. No msg was
>> lost, very reliable.
>> Incomming message will be rejected or jammed once the broker's buffer was
>> full. The Task
>> Maneger shown pauses on outgoing rate.
>>
>> I want the federation behave like that, jam the sender once the broker's
>> buffer was full and
>> don't drop any message. What did I miss?
>>
>> Sorry for the english, I am not a native english speaker.
>>
>> Harris
>>
>
>
Re: 0.30 C++ Broker: MsgDrop in topic exchanges' dynamic route
Posted by Haoliang Chen <ch...@gmail.com>.
The result is easier to reproduce if the dest broker was
set --default-queue-limit 10240.
And the dest broker will throw:
2015-07-23 14:31:43 [Broker] warning Exchange My.topic cannot deliver to
queue My.topic_284ad1f5-b871-4c13-9a59-f1d6319b8286:
resource-limit-exceeded: Maximum depth exceeded
on My.topic_284ad1f5-b871-4c13-9a59-f1d6319b8286: current=[count: 8, size:
9152], max=[size: 10240]
(/home/MQ/qpid-cpp-0.32/src/qpid/broker/Queue.cpp:1628)
As you see, this problem also happened on 0.32 Brokers.
2015-07-22 17:33 GMT+08:00 Haoliang Chen <ch...@gmail.com>:
> Hello all,
>
> I was attempting to establish a reliable route between two exchanges on
> two brokers, but
> failed. It seem like the packages start to be dropped by the source broker
> once its buffer
> was full. I want the source broker stop to recive if its buffer was full.
>
> I have a federation consist of two 0.30 brokers on different computers,
> donate by B1 and B2.
> Both run on the same config,
>
> auth=no
> realm=QPID
> data-dir=/home/MQ/broker-data/
>
> And I new a exchange on both brokers using the following command:
> qpid-config -b B1 add exchange topic My.topic --durable
> qpid-config -b B2 add exchange topic My.topic --durable
>
> Then I add route:
> qpid-route -d --ack=10 dynamic add B1 B2 My.topic
> qpid-route -d --ack=10 dynamic add B2 B1 My.topic
>
> Then I start to recived from B1 with the 0.32 qpid-recieve on Windows:
> qpid-receive -b B1 -a My.topic --verify-sequence --print-content 0
> --timeout 100
> --report-every 100000
>
> And I start to flood B2 with the 0.32 qpid-send on Windows:
> qpid-send -b B2 -a My.topic -m 0 --durable yes --content-size 10240
> --report-every 100000
>
> Not long after, the qpid-receive stop and I Got:
> qpid-receive: Gap in sequence numbers 18987-19742
> (..\..\..\qpid-cpp-0.32\src\te
> sts\qpid-receive.cpp:172)
>
> Meanwhile the qpid-send keep running and sending. The Task Manager shown a
> static outgoing
> rate.
>
> Here are the output of #qpid-stat -e -b B1
> Exchanges
> exchange type dur bind msgIn msgOut msgDrop byteIn
> byteOut byteDrop
>
> ===========================================================================================
> direct 2 0 0 0 0
> 0 0
> My.topic topic Y 0 110k 29.8k 81.1k 1.14g
> 307m 835m
> ...
>
> Here are the output of #qpid-stat -e -b B2
> Exchanges
> exchange type dur bind msgIn msgOut msgDrop byteIn
> byteOut byteDrop
>
> ===========================================================================================
> direct 2 0 0 0 0
> 0 0
> My.topic topic Y 0 29.6k 29.6k 0 306m
> 306m 0
> ...
>
> And the network info:
> WindowsClient to B1/B2 is faster than B1/B2 to WindowsClient;
> B1/B2 is connected to the same switch.
>
> If I send to and receive form the same broker, it works well. No msg was
> lost, very reliable.
> Incomming message will be rejected or jammed once the broker's buffer was
> full. The Task
> Maneger shown pauses on outgoing rate.
>
> I want the federation behave like that, jam the sender once the broker's
> buffer was full and
> don't drop any message. What did I miss?
>
> Sorry for the english, I am not a native english speaker.
>
> Harris
>