Ah never mind I see you answered, apologies. Let me ask you this: am I
stuck with all of these default-executor threads that my process is
spawning? Is there no way to limit them? Do they come from same pool as
grpc sync server threads?
On Wed, Jan 5, 2022 at 3:51 PM Jeff Steger wrote:
> Can
Can you specifically answer this:
grpc-java has a method in its ServerBuilder class to set the Executor. Is
there similar functionality for grpc-c++ ?
Thanks!
On Tue, Jan 4, 2022 at 11:55 AM Mark D. Roth wrote:
> I answered this in the other thread you posted on.
>
> On Sun, Jan 2, 2022 at
Could one of the developers please elaborate on the case where:
* The sender has been blocked (shortly) on a closed TCP Window leaving a
large set of gRPC chunks waiting at the HTTP2 stream sender side
* The receiver has not send a OUTBOUND WINDOW_UPDATE to signal its OK to
send more data.
My
So the stream is stalled as the congestion window is closed. Just verified
with tcpdump and tcptrace, and can confirm thats the problem.
https://github.com/grpc/grpc/blob/2e3e3ccc3d5c40010a6ad6f824a5024176a7/src/core/ext/transport/chttp2/transport/writing.cc#L449
This explains why excessive
Hello Everyone,
I have implemented a proto file by checking the internet with one unary rpc
service and stream service. I done the coding part for the unary rpc
service with c++ for both client and the server. But the second service
(stream) i cannot able to build the logic on how to send a
After sending some data (about 4 chunks of 16k of a single 1Mb gRPC
message) the HTTP2-stream seems to be put on the "stalled" list. (Whatever
that may be).
World.Hello World.Hello World.Hello World.Hello
World.Hello World.Hello World.Hello World.Hello
I managed to extract some logging, the python side seems to send a too
large frame.
[id: 0x0e0792ca, L:/127.0.0.1:43718 - R:localhost/127.0.0.1:60630] Sent
GOAWAY: lastStreamId '2147483647', errorCode '6', debugData 'Frame length:
2165320 exceeds maximum: 16384'. Forcing shutdown of the
