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
The server sets keep-alive on accepted connections, so as far as I can tell this was a live client which had started a read RPC, but was then making no progress reading the response stream from the broker. The broker wanted to exit, but the gRPC server's GracefulStop was being held up by the client's Read RPC already underway. The proxy Read RPC knows to check for shutdown and send an EOF to the client, but the current mechanism doesn't take into account that SendMsg can block indefinitely.
This may be a concern with non-proxied reads as well, but I was only able to find traces involving proxied reads for some reason.
The text was updated successfully, but these errors were encountered:
To resolve this, I'm adding a timeout (15s) of how long we'll wait for GracefulStop to complete. After that point, a hard gRPC server Stop is issued. This has the benefit of causing offending RPCs to bail out, logging errors like:
Grabbed this off of a production broker which was taking quite a while to exit:
The server sets keep-alive on accepted connections, so as far as I can tell this was a live client which had started a read RPC, but was then making no progress reading the response stream from the broker. The broker wanted to exit, but the gRPC server's GracefulStop was being held up by the client's Read RPC already underway. The proxy Read RPC knows to check for shutdown and send an EOF to the client, but the current mechanism doesn't take into account that
SendMsg
can block indefinitely.This may be a concern with non-proxied reads as well, but I was only able to find traces involving proxied reads for some reason.
The text was updated successfully, but these errors were encountered: