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 <g...@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-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > >
