qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pankaj Bhagra <pans...@gmail.com>
Subject Re: proton server (azure SB) limit the incoming_window=5000
Date Thu, 10 Aug 2017 17:54:06 GMT
My interest piqued by your pointer of forcing negotiation for getting
"settled" messages s.t. server can keep sending them without awaiting
client to acknowledge them. So i tried your recommendation of setting the
link option AtMostOnce. I went further and force the AtMostOnce to set the
"settled" for both send and receive message. However i still see server
doesn't release the next batch till it receive the acknowledgement from
client. this is puzzling, any other suggestion ?

I wanted to experiment by disabling the flowControl. i did that by setting
"prefetch"="None" , but that didn't get going. what would be way to disable
the flow control to try out ?

[0x24b0cd0]:0 -> @open(16)
[container-id="3feb8312-b228-4052-87ec-5ab12633be0c", hostname="
nebhubsb.servicebus.windows.net", channel-max=32767]

[0x24b0cd0]:0 -> @begin(17) [next-outgoing-id=0,
incoming-window=2147483647, outgoing-window=2147483647]

[0x24b0cd0]:0 -> @attach(18)
[name="3feb8312-b228-4052-87ec-5ab12633be0c-kukatopic/Subscriptions/kukasub",
handle=0, role=true, snd-settle-mode=1, rcv-settle-mode=1,
source=@source(40) [address="kukatopic/Subscriptions/kukasub", durable=0,
timeout=0, dynamic=false], target=@target(41) [durable=0, timeout=0,
dynamic=false], initial-delivery-count=0, max-message-size=0]

[0x24b0cd0]:0 -> @flow(19) [incoming-window=2147483647, next-outgoing-id=0,
outgoing-window=2147483647, handle=0, delivery-count=0, link-credit=100,
drain=false]

[0x24b0cd0]:  <- AMQP

[0x24b0cd0]:0 <- @open(16)
[container-id="2fdaeda28fb7483a9922790398ad1f0a_G20", max-frame-size=65536,
channel-max=4999, idle-time-out=240000]

[0x24b0cd0]:0 <- @begin(17) [remote-channel=0, next-outgoing-id=1,
incoming-window=5000, outgoing-window=2147483647, handle-max=255]

[0x24b0cd0]:0 <- @attach(18)
[name="3feb8312-b228-4052-87ec-5ab12633be0c-kukatopic/Subscriptions/kukasub",
handle=0, role=false, snd-settle-mode=1, source=@source(40)
[address="kukatopic/Subscriptions/kukasub", durable=0, timeout=0,
dynamic=false], target=@target(41) [durable=0, timeout=0, dynamic=false],
initial-delivery-count=0, max-message-size=266240]

[0x24b0cd0]:0 <- @transfer(20) [handle=0, delivery-id=0, delivery-tag=b"",
message-format=0, settled=true, more=false, batchable=true] (1220)

[0x24b0cd0]:0 <- @transfer(20) [handle=0, delivery-id=1, delivery-tag=b"",
message-format=0, settled=true, more=false, batchable=true] (1231)

[0x24b0cd0]:0 <- @transfer(20) [handle=0, delivery-id=2, delivery-tag=b"",
message-format=0, settled=true, more=false, batchable=true] (1219)

[0x24b0cd0]:0 <- @transfer(20) [handle=0, delivery-id=3, delivery-tag=b"",
message-format=0, settled=true, more=false, batchable=true] (1219)

[0x24b0cd0]:0 <- @transfer(20) [handle=0, delivery-id=4, delivery-tag=b"",
message-format=0, settled=true, more=false, batchable=true] (1219)

[0x24b0cd0]:0 <- @transfer(20) [handle=0, delivery-id=5, delivery-tag=b"",
message-format=0, settled=true, more=false, batchable=true] (1270)

[0x24b0cd0]:0 <- @transfer(20) [handle=0, delivery-id=6, delivery-tag=b"",
message-format=0, settled=true, more=false, batchable=true] (1218)

[0x24b0cd0]:0 <- @transfer(20) [handle=0, delivery-id=7, delivery-tag=b"",
message-format=0, settled=true, more=false, batchable=true] (1229)

[0x24b0cd0]:0 <- @transfer(20) [handle=0, delivery-id=8, delivery-tag=b"",
message-format=0, settled=true, more=false, batchable=true] (826)

[0x24b0cd0]:0 <- @transfer(20) [handle=0, delivery-id=9, delivery-tag=b"",
message-format=0, settled=true, more=false, batchable=true] (1218)

[0x24b0cd0]:0 <- @transfer(20) [handle=0, delivery-id=10, delivery-tag=b"",
message-format=0, settled=true, more=false, batchable=true] (1220)

[0x24b0cd0]:0 <- @transfer(20) [handle=0, delivery-id=11, delivery-tag=b"",
message-format=0, settled=true, more=false, batchable=true] (1216)

[0x24b0cd0]:0 <- @transfer(20) [handle=0, delivery-id=12, delivery-tag=b"",
message-format=0, settled=true, more=false, batchable=true] (1216)

2017-08-10 01:49:00.417 pkt_seq = 1 remaining_in_batch = 12, 879

2017-08-10 01:49:00.417 pkt_seq = 2 remaining_in_batch = 11, 890

2017-08-10 01:49:00.417 pkt_seq = 3 remaining_in_batch = 10, 878

2017-08-10 01:49:00.418 pkt_seq = 4 remaining_in_batch = 9, 878

2017-08-10 01:49:00.419 pkt_seq = 5 remaining_in_batch = 8, 878

2017-08-10 01:49:00.419 pkt_seq = 6 remaining_in_batch = 7, 929

2017-08-10 01:49:00.419 pkt_seq = 7 remaining_in_batch = 6, 877

2017-08-10 01:49:00.420 pkt_seq = 8 remaining_in_batch = 5, 888

2017-08-10 01:49:00.420 pkt_seq = 9 remaining_in_batch = 4, 500

2017-08-10 01:49:00.421 pkt_seq = 10 remaining_in_batch = 3, 877

2017-08-10 01:49:00.421 pkt_seq = 11 remaining_in_batch = 2, 879

2017-08-10 01:49:00.421 pkt_seq = 12 remaining_in_batch = 1, 875

2017-08-10 01:49:00.422 pkt_seq = 13 remaining_in_batch = 0, 875

[0x24b0cd0]:0 -> @flow(19) [next-incoming-id=14,
incoming-window=2147483647, next-outgoing-id=0, outgoing-window=2147483647,
handle=0, delivery-count=13, link-credit=99, drain=false]

[0x24b0cd0]:0 <- @transfer(20) [handle=0, delivery-id=13, delivery-tag=b"",
message-format=0, settled=true, more=false, batchable=true] (1218)


and cycle continues ..




On Thu, Aug 10, 2017 at 3:01 AM, Gordon Sim <gsim@redhat.com> wrote:

> On 10/08/17 00:13, Pankaj Bhagra wrote:
>
>> Gordon,
>>
>> Further digging on network level sniffing shows that the bulk msg_size is
>> limited to = 16373 (16K). this observation is inline with previously
>> reported issue
>>
>
> What do you mean by msg_size here?
>
> http://grokbase.com/t/qpid/users/163z91rhdy/ssl-maximum-message-size
>>
>
> Interesting that the limit is the same, not sure what to make of that,
> perhaps its just a commonly used buffer size. The 'solution' in that issue
> was to break up large messages into multiple frames. In your case as I
> understood it, the individual messages were smaller than this limit already.
>
> As suggested I posted the q on the Azure SB forum too to find if there are
>> knobs in the SB configuration to make this un-ack buffer size bigger on
>> the
>> amqp ssl.
>>
>> Coming back on your suggestion about unsettled messages. Can u guide me
>> what should be client side configuration (if any) to force server to keep
>> sending without waiting for flow control ack from the client (number of
>> unsettled messages ?). I would like server to stop on the link-credit
>> running out, but not on the max_buffer of 16kb. Ideally  i need is a
>> behavior of atleast-once, but I am ready to sacrifice this requirement to
>> get better perf.
>>
>
> To request that message be sent settled, you can create your receiver with
> the AtMostOnce option (imported from proton.reactor), e.g.:
>
>   container.create_receiver(url, options=[AtMostOnce()])
>
> or
>
>   container.create_receiver(conn, 'mysource', options=[AtMostOnce()])
>
> You could see if that has any effect.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message