amqp — archive

AW: [amqp] Size-based link flow control

From: Clemens Vasters
To: [email protected]
Date: Fri, 08 Mar 2019 23:07:00 -0000

The session flow control has frame-size resolution and we also use that to cap memory use in the gateway. The links end up interacting with the respective link target s backend processor/storage. We do have the scenario where a single inbound session carries a bundle of links where each link talks to a different backend. For that, the team wants finer grained flow control metric than a message count. Von: Alan Conway <[email protected]> Gesendet: Freitag, 8. MÃrz 2019 12:46 An: Clemens Vasters <[email protected]> Cc: [email protected] Betreff: Re: [amqp] Size-based link flow control Qpid Dispatch uses the existing byte-based session flow control to bound its memory use. It does effectively block clients that send a lot of bytes - regardless of whether it is many small messages or some very large ones. Why do you need a per-link limit on top of that? A per-link limit allows senders that create a ton of links to blow up the receiver. Of course a malicious sender could create a ton of sessions, but that's much less likely to happen by accident, and the max number of sessions is easy to limit giving you a guaranteed upper-bound on memory per connection. On Fri, Mar 8, 2019 at 2:34 PM Clemens Vasters < [email protected] > wrote: Our engineering team has the strong desire to add a flow control mode where link-credit is counted in bytes rather than in number of messages. We re occasionally getting into the situation where we re being hammered with a ton of large messages all at once and team is convinced that a byte-oriented credit counter could allow for tighter control of what the client are allowed to push. For session-based flow control, the permitted windows we need are also too big. The Flow control section 2.6.7. in the core spec is surprisingly vague and doesn t have a hard reference to link-credit being a message counter. The only hard reference seems to be is in 2.7.4. where the link-credit section says that The current maximum number of messages that can be handled at the receiver endpoint of the link So we re thinking about an extra spec with a layered-on capability that allows for reinterpretation of link-credit and delivery-count as counts of bytes. Thoughts?