Cap total number of concurrent commands per 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 Conceptually everything looks good to me. However as far as I can see you are also mixing in some code optimization into the same change-set.

Could you please do this?

1. Spin the optimization code into a separate pull request. It should get merged in first.
2. Re-base this pull request off it
3. Provide the same logic to HttpAsyncRequester for consistency.

[arturobernalg]

@arturobernalg Conceptually everything looks good to me. However as far as I can see you are also mixing in some code optimization into the same change-set.

Could you please do this?

1. Spin the optimization code into a separate pull request. It should get merged in first.

2. Re-base this pull request off it

3. Provide the same logic to `HttpAsyncRequester` for consistency.

@ok2c Please another pass

[ok2c]

@arturobernalg Almost there. Just a few comments.