Keepalive should work here. You'll have to configure a few other params if
you have long lived streams with low activity. Along with
keepalive_permit_without_calls, you may have to configure
max_pings_without_data or min_sent_ping_interval_without_data too. You may
also have to configure min_re
Hey Srini,
I've tested pretty aggressive KeepAlive config with the following
parameters:
'grpc.http2.min_time_between_pings_ms': 1000,
'grpc.keepalive_time_ms': 1000,
'grpc.keepalive_permit_without_calls': 1
Is there anything I'm missing? Ideally I would like this solution to handle
both expli
It looks like python does not have the API to set wait_for_ready :-(
On Friday, August 17, 2018 at 5:17:43 PM UTC-7, Srini Polavarapu wrote:
>
> Hi Alysha,
>
> How did you confirm that client is going into backoff and it is indeed
> receiving a RST when nginx goes away? Have you looked at the log
Hi Alysha,
How did you confirm that client is going into backoff and it is indeed
receiving a RST when nginx goes away? Have you looked at the logs gRPC
generates when this happens? One possibility is that nginx doesn't send RST
and client doesn't know that the connection is broken until TCP ti
Hey Carl,
This is with L7 nginx balancing, the reason we moved to nginx from L4
balancers was so we could do per-call balancing (instead of per-connection
with L7).
> In an ideal world, nginx would send a GOAWAY frame to both the client
and the server, and allow all the RPCs to complete befor
Hi Alysha,
Do you you know if nginx is balancing at L4 or L7?In an ideal world,
nginx would send a GOAWAY frame to both the client and the server, and
allow all the RPCs to complete before tearing down the connection. The
client knows how to reschedule and unstarted RPC onto a different
