-
-
Notifications
You must be signed in to change notification settings - Fork 83
Send a close to all websocket connections when server closes #46
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
Conversation
delvedor
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I’m not sure if it is worth to add a new hook since this seems an edge case related to this module.
I’m wondering if we should be more aggressive when closing in fastify itself by using something like https://www.npmjs.com/package/stoppable.
|
stoppable tracks all open sockets in a map. From my tests this lead to a significant overhead in term of throughput. Note that we are already supporting that use case with the use of timeouts, so we don’t need stoppable for this to work. We can land this and possibly add another hook or add prependHook to add an hook at the first position. |
|
Could we improve this feature request fastify/fastify#1795 with a TODO list? Anyway, I think a |
|
Have you folks further developed your thinking around this? It would be super awesome to have this just work by default -- happy to contribute if I can! |
Eomm
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the delay
delvedor
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
As noted by @franky47 in #45, the http server close callback does not fire until all connections are closed. This works extremely well for http requests, because it allows to wait until everything is done. It does not work well for websockets, because we need to call a method in each of them
close(), hence I monkeypatch the server.close method.I think we should send a PR to fastify to add the ability to handle this specific case.
This is a draft PR because the behavior should likely be customizable, i.e. the
client.close()accepts a code and a message.Fixes #45.
Checklist
npm run testandnpm run benchmark