fishy commented on pull request #2497: URL: https://github.com/apache/thrift/pull/2497#issuecomment-1011620472
>for the error rate, from the server's pov，the client may also close abruptly to cause server error. That's much less important for the majority of servers and that's already supported by connectivity check: https://github.com/apache/thrift/blob/master/lib/go/README.md#a-note-about-server-handler-implementations I don't know what's your production setup. For a typical stateless thrift server running on kubernetes, each individual servers (pods in kubernetes teminology) are running behind a shared "service" that's acting as load balancer. clients talks to this service instead of individual pods, and the service will choose a pod to connect the client to. When a pod is shutting down, the service will no longer assign any new clients to it, but will use other pods to handle those requests. The pods are also usually on horizontal auto scaler (hpa) that auto scales up and down based on the traffic. In majority of the cases, there are only two scenarios a pod would be shutdown (this is where `TSimpleServer.Stop` is called): 1. the hpa decides to scale down (for example, you are moving away from peak business hours), so it reduce the number of pods (choose some pods to shut them down). 2. you are doing a rolling release, so the pods are being replaced. In either case, graceful shutdown makes sure that no requests gets interrupted by the graceful shutdown, which is commonly referred to as "zero downtime". When kubernetes decides to kill a pod (in either case), it first sends a shutdown signal to your running process, then wait for shutdown timeout. Your code handles the signal, and call `TSimpleServer.Stop` as a result of that, and wait for the shutdown/cleanup to complete. The only downtime (failed requests) are caused by it takes longer than the shutdown timeout to finish (if the process does not stop after the shutdown timeout, kubernetes controller will just kill the process forcefully). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
