On 10/08/17 00:13, Pankaj Bhagra wrote:

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?


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()])


  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

Reply via email to