Why not call server.close immediately?

[glasser]

I'm evaluating http-terminator, stoppable, and others.

http-terminator looks really nice in general. One thing I'm confused about, though: why doesn't it call server.close immediately on terminate? It looks like http-terminator first waits for all existing connections to close (helping that along in various ways), and only then actually closes the listener socket with server.close. Can't the server.close call be moved up the function above the various await delay calls, so that new connections fail at the TCP level immediately?

[gajus]

Because (depending on the context in which http-terminator is used), it may be desirable to accept connections for a short time after receiving a signal to terminate, e.g. Kubernetes will send a SIGKILL, but it may still send new requests to the app afterwards.

[bizob2828]

I'm still digging into the root cause but I think I'm seeing an issue with this as well. I have this running in containers that are being load balanced with nginx. When the container stops the SIGTERM is sent which is where I call terminate. I noticed a few requests get closed and nginx responds with recv() failed (104: Connection reset by peer) while reading response header from upstream. Any ideas?

[nflaig]

I noticed a few requests get closed and nginx responds with recv() failed (104: Connection reset by peer) while reading response header from upstream. Any ideas?

I know this was asked quite a while ago but your issue would also happen if the http server was closed immediately.

What http-terminator does right now, is that while terminating, new connections are just force closed by destroying the socket.

http-terminator/src/factories/createInternalHttpTerminator.ts

Lines 40 to 41 in aabca47

	if (terminating) {
	socket.destroy();

The result of this is not much different compared to closing http server first, in both cases there will be errors if a client tries to connect after shutting down.

I am not exactly sure how you are running the containers but this is a common issue on kubernetes during rolling updates due to the fact that the endpoint de-registration happens asynchronously, see kubernetes/kubernetes#43576.

The only way to fix this is to delay sending SIGTERM to your application after pod received signal by overriding preStop hook.

lifecycle:
  preStop:
    exec:
      command: ["sleep", "5"]

This hashicorp/consul-k8s#650 explains the issue in more detail.