I have created a minimal express POC having only one base route sending hello world after 30s, using setTimeout.
I sent an HTTP request and started to wait. Meanwhile I tracked the PID of the node and killed it from the terminal.
The SIGTERM event was fired and handled like this:
process.on('SIGTERM', () => {
console.log(`[SIGTERM received]`)
console.log(`[closing http server]`)
server.close(() => {
console.log(`[Http server closed]`)
process.exit(0)
})
})
The first two logs appeared and if I tried to set another http request, it was failed. Exactly what I wanted to have. BUT, by the time that the first http request was finally fulfilled and returned, there was a gap of maybe 3-5 seconds that I could thread another http request! and then it could wait another 30s and fulfilled and then I could set another and so for and so on.
If there tons of requests, k8s for example, will shut it down ungracefully at all and all of those requests will be failed (reaching a timeout).
Why does it happen, does it a bug in Nodejs v14? When the last http request has ended, the process should stop immediately and never receive any kind of another request. And then tell to some manager like k8s that the container is now stopped and that it is allow to terminate the pod.
The full behaviour should be like this:
Lets say we have only one pod.
Then we upgrade the version.
K8S Starts to create a new pod and by the time the new pod is created it stop routing any new request to the old one.
It doesn't and shouldn't terminate the old pod, unless its clearly says that he was done serving the last http request.
Then the old pod should be terminated and we have a zero downtime - one of the core reasons to use K8S.
