-
Notifications
You must be signed in to change notification settings - Fork 646
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HTTP2 - Round-robining streams across a minimum setting of connections #1808
Comments
@crankydillo Can you elaborate more on this |
Currently, you only get a new connection from the underlying pool if requests are made in parallel in certain ways or if you have exhausted the max streams on a connection. In the latter case, that can result in max streams requests all getting sent to one server that sits behind an L4 load balancer. What we want is to specify at the client level that the some minimum number of connections should be used to round-robin the streams. With that, we get some client-side load-balancing of requests. We also close connections from the server and are assuming that graceful handling of that will happen in the client. |
If the above doesn't help, my precise definition of that prhase is: Up to some number (the minimum) the client will open a new connection when creating a new stream as opposed to creating an additional stream on a connection that is already in the HTTP/2 pool. |
@violetagg There is another aspect of this that we need to get clarity on. We are hoping that new (socket) connections will be gated by this minimum pool until For example, if we have:
We will get ~100 socket connections created because of the concurrency level in flatMap. However, we'd like to guarantee that socket connections will remain below or equal to the min-pool size feature you are working in this feature request until We feel like this min pool feature is related to this and apologize for throwing this in now. What do you think? Do you agree with our concern above? |
Hello. Just wanted to touch base on this. It looks like it's not a high priority for you, but it currently still is for us. What do you think about us making a contribution? Overly difficult? We know reactor-pool has a minimum-resource type of concept. I tried a quick hack to make the underlying pool have a minimum size (even though I know you have checks like this), but it failed. Is that a bad route? We can poke around more, but if you have any suggestions, we welcome them:) Also, if you don't plan on dealing with any PRs related to this feature in the near term, that would be good information for us to know as well. Many thanks for all the hard work! |
@crankydillo Let me schedule this for 1.0.18. We won't be able to work on this for 1.0.17 (release is next week). Is that OK? |
Thank you Violeta. I'm pretty sure I know the answer, but just in case.. Will you be able to consider a PR targeting 1.0.17? |
I'll be able to review a PR |
before spawning multiple streams on any given socket connection. reactor#1808
@violetagg You asked on the PR what the requirements are. I'm trying to get that written up nicely. The main requirement remains that a specifiable minimal number of socket connections are created before any additional streams are created on an existing socket connection. However, what do you think about the scenario above? |
Update: The exact requirements: #2091 (comment)
@crankydillo For the next release which is next Tuesday (12.04) I will be able to expose a configuration for specifying a minimum number of connections and a
We do use round-robin as of today. I cannot understand this requirement. |
@crankydillo PTAL #2155 |
Thanks @violetagg . We plan on looking at your PR soon! |
The enhancement is available in 1.0.20-SNAPSHOT. It will be great if you can test it. The min connections can be configured via the new
|
@violetagg I'm sorry I missed this. I know it's quite late, but I will try this out! |
I tried it out. Pretty sure it's going to work out like we hoped. Thanks for implementing! |
We leverage L4 load balancers for distributing load, resiliency needs, etc. We are thinking 2 additions (likely opt-in) to the HTTP2 pool could help us in this regard:
Some of the above was initially discussed here.
The text was updated successfully, but these errors were encountered: