Cap total number of concurrent requests per HTTP/2 connection

[arturobernalg]

This change adds an optional hard cap on the number of pending request execution commands queued per HTTP/2 connection. When the per-connection limit is reached, new submissions fail fast with RejectedExecutionException and the exchange handler releases its resources immediately. The cap is configured via H2MultiplexingRequesterBootstrap and passed into H2MultiplexingRequester at construction time to keep requester configuration immutable and avoid API incompatibilities.

[ok2c]

@arturobernalg I do not like this approach. There is already a command queue built into the IOSession. We should leverage that queue instead of creating another layer of complexity. What we need is to extend IOSession interface to expose information about already pending commands and optionally reject commands if the queue is over a particular limit.

[arturobernalg]

@arturobernalg I do not like this approach. There is already a command queue built into the IOSession. We should leverage that queue instead of creating another layer of complexity. What we need is to extend IOSession interface to expose information about already pending commands and optionally reject commands if the queue is over a particular limit.

@ok2c . Sorry about the churn — I’m still getting up to speed on this part of the reactor stack and my previous commit took a wrong turn. I dropped the extra wrapper and enforce the cap via the existing IOSession command queue. I extended IOSession with a bounded enqueue + pending count and delegated through InternalDataChannel and SSLIOSession so the limit is not bypassed by decorators.

[ok2c]

@arturobernalg I think the method by default return -1 as not known

[ok2c]

@arturobernalg I would not do that on the i/o session level. Different protocol handlers may have different restrictions. 10 concurrent requests may be perfectly OK for HTTP/2 and too much for HTTP/1.1. Please move this logic to individual protocol handlers.