You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are switching from C-based gRPC to .NET gRPC implementation. In the C-based implementation we have a lot of options to configure keep-alive described here: https://github.com/grpc/grpc/blob/master/doc/keepalive.md we use this to ensure that idle connections are removed in order to avoid resource leaks. These kind of options do not seem to be present in .NET gRPC. This is problematic when using client and bidirectional streaming calls as the execution will be stuck at "MoveNext()" which will never return or throw an exception. Also, the TCP connection is never removed.
The only solution we have found so far is to handle it in the application layer where we have a timeout if no data has been received from the client. This will both end the request and the TCP connection, however, this is not a great solution since we will have to do this for all streaming calls and if this is forgotten it will cause memory leak.
Is this the only way to handle idle request/tcp connections are we missing something?
The text was updated successfully, but these errors were encountered:
Uh oh!
There was an error while loading. Please reload this page.
We are switching from C-based gRPC to .NET gRPC implementation. In the C-based implementation we have a lot of options to configure keep-alive described here: https://github.com/grpc/grpc/blob/master/doc/keepalive.md we use this to ensure that idle connections are removed in order to avoid resource leaks. These kind of options do not seem to be present in .NET gRPC. This is problematic when using client and bidirectional streaming calls as the execution will be stuck at "MoveNext()" which will never return or throw an exception. Also, the TCP connection is never removed.
The only solution we have found so far is to handle it in the application layer where we have a timeout if no data has been received from the client. This will both end the request and the TCP connection, however, this is not a great solution since we will have to do this for all streaming calls and if this is forgotten it will cause memory leak.
Is this the only way to handle idle request/tcp connections are we missing something?
The text was updated successfully, but these errors were encountered: