Skip to content
This repository has been archived by the owner on Apr 14, 2023. It is now read-only.

How to handle SIGTERM with this? #746

Closed
fabis94 opened this issue Mar 11, 2020 · 1 comment
Closed

How to handle SIGTERM with this? #746

fabis94 opened this issue Mar 11, 2020 · 1 comment

Comments

@fabis94
Copy link

fabis94 commented Mar 11, 2020

It's not clear how to make the WebSocket server stop accepting new connections, finish all pending operations and close the sockets, when SIGTERM is received. Has anyone dealt with this?

@jedwards1211
Copy link
Contributor

jedwards1211 commented Apr 21, 2020

Looks like the server does have a close() method that closes the WebSocket server. That definitely makes it stop accepting new connections.

But, looking at the ws code, it terminates all clients, which I'm pretty sure means it closes them immediately instead of waiting for pending operations to finish.

So instead of calling close() right away, you'd probably need to manually handle HTTP upgrade requests yourself so that you can stop passing them to the WebSocket server after you've received SIGTERM. For some examples on how to handle the upgrades manually, see apollographql/apollo-server#2314 (comment) and my gist linked earlier in that comment thread.

As far as waiting for pending operations to finish, I'm not 100% sure. You might need to put some middleware between each socket and subscriptions-transport-ws to stop accepting new subscription requests after SIGTERM is received.

That said, it does seem like this library would be the best place to perform a managed shutdown, if an API for it could be added.

@glasser glasser closed this as completed Mar 3, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants