Yes, this is on purpose, and is actually expected per the HTTP/2 spec
<https://datatracker.ietf.org/doc/html/rfc7540#section-9.1>. We recognize
there are situations where that is not the correct behavior and more
connections should be opened, although that point may be *before* hitting
MAX_CONCURRENT_STREAMS. Determining when to open more connections is a bit
involved as it depends on your load balancer approach. It isn't helped by
the fact that MAX_CONCURRENT_STREAMS can be dynamic and servers are allowed
to set MAX_CONCURRENT_STREAMS to 0 (momentarily); that's actually something
C core can do when under extreme memory pressure. Opening more connections
can make overload situations worse. Anyway, it is complicated. Clients that
just open more connections tend to assume high-scale internet load
balancers that can accept ~infinite number of connections and use
hard-coded MAX_CONCURREN_STREAMS.

Using a solution like ChannelPool (linked in Yuri's email) is the suggested
workaround in Java; it is a bigger issue in some other languages where you
don't have a small Channel interface that the stubs use.

On Tue, Jun 15, 2021 at 10:22 PM 'Gaurav Poothia' via grpc.io <
[email protected]> wrote:

> Hello!
> I have a situation where the server sets H/2 max concurrent streams
> intentionally low (e.g. 16 or 32) for good reason (that are somewhat
> orthogonal to gRPC so I will skip the details)
> The behavior I seem to be observing is that Java gRPC client stalls when
> it hits that limit and waits for streams to free up before issuing more
> requests.
> Is this the expected behavior?
>
> I was hoping for a knob that allows me to instruct gRPC to dial additional
> H/2 connections when it hits the limit. Turns out the .Net implementation
> has something exactly  like that
>
> https://docs.microsoft.com/en-us/aspnet/core/grpc/performance?view=aspnetcore-5.0#connection-concurrency
>
> Does Java gRPC stack have an equivalent?
>
> It would be pretty useful in seamlessly handling service to service
> communication where server can support a higher gRCP req/sec but only if
> the client were to dial more H/2 connections.
> I say "seamlessly" because of course we can write code to somehow dial
> more subchannels to server but we want the client to do this automatically
> without programmer picking hardcoded connection count.
>
> Thanks in advance!
> Gaurav
>
> --
> You received this message because you are subscribed to the Google Groups "
> grpc.io" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/a687afdc-6c52-449f-85ab-5c9d83543f08n%40googlegroups.com
> <https://groups.google.com/d/msgid/grpc-io/a687afdc-6c52-449f-85ab-5c9d83543f08n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CA%2B4M1oNt6N5B%2B6E_MLMo6EDWjA%2Boons2ZLe9dfJj9JXZ_wMssA%40mail.gmail.com.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to