Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gracefully close server connections on SIGTERM. #11

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

skewart
Copy link

@skewart skewart commented Jan 26, 2016

This should make it a little safer to restart the server.

relevant:
http://joseoncode.com/2014/07/21/graceful-shutdown-in-node-dot-js/
expressjs/express#1366

@kainosnoema
Copy link

This will only help if the connection closes in < 10s right? Long downloads may take several minutes. This helps, just not a whole lot.

We may want to look into server buffering in Nginx to see if that lets us close the server connection before the client is finished receiving data.

Otherwise the only other alternative is to do proper graceful restarts by sharing a UNIX socket.

@kainosnoema
Copy link

LGTM

@skewart
Copy link
Author

skewart commented Jan 26, 2016

I think your assessment of the situation is correct.

Honestly, there are a number of things that I'm not entirely.

  1. What happens when the server shuts down. Do the Squirrel clients try to connect again? (Squirrel source might give a clue, but I'm wondering if there is anything in the HTTP protocol that instructs you to try again if the TCP connection closes, or something like that.)

  2. How exactly does sharing a unix socket help with long downloads? (btw, I'm assuming this would be instead of proxying http over localhost) Is it that Nuts can quickly write the bytes to the socket, and then nginx handles the slow transmission of those bytes to the client? What about the fact that Nuts is itself a proxy to Github? It does cache things though, but only for a limited time. (Though, yeah, in most cases it will be serving assets locally.)

  3. What is served buffering in nginx? (this should be easy to Google).

@kainosnoema
Copy link

  1. There's nothing in the HTTP protocol itself. Squirrel might reattempt, but most likely it'll just fail until the next update attempt.

  2. By using a UNIX socket, the process can fork, the child can start accept()'ing on the shared socket, the parent can let any requests finish (even for minutes), and then gracefully dies when it's done. This is how both homebase and curator do zero-downtime restarts.

  3. Via Google: http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_buffering

@skewart
Copy link
Author

skewart commented Jan 26, 2016

👍

@skewart
Copy link
Author

skewart commented Jan 26, 2016

To do the forking with the unix socket, it sounds like you'd need more than one or two lines of logic for that. I'm thinking there's probably a module for that. (maybe forever?) I'll look into it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants