-
Notifications
You must be signed in to change notification settings - Fork 327
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
Hook to know when unit wants to shut down #581
Comments
Hello, It seems I understand what you are trying to achieve. According to ASGI Spec, the
And there is no events in specification to send before active connections closed :( For investigation purpose, I've added logging to sample ASGI WebChat application (see attached asgi_chat.zip ) and run it under uvicorn-0.15.0, daphne-3.0.2 and hypercorn-0.11.
I assume there can be issues with Unit's ASGI implementation, so could you please describe the solution which works for other ASGI server(s). |
Based on above, I believe uvicorn follows the spec properly (and would fix my issue). Hypercorn and Unit do not.
The closing of connections clause above implies that the server will actively close connections, not passively wait for them to close. My issue is that the Unit server does not close the sockets and my application has no way of knowing when we enter this state, so my application cannot close them. Any clients connected to the wanting-to-die instance will stay connected and prevent the process from shutting down. I suggest that Unit either should adopt uvicorn's lifespan behavior, or provide an alternate facility for application code to know when the server wants to shut down. -K |
To reproduce your issue should I stop Unit or reconfigure application? |
Reconfigure application. What I am doing is:
This should cause old unit instances to shut down. Reconfigure with ENV change or similar should do the same thing. Thanks, -K |
I am using the channels chat example. After reconfigure, the old processes are still running. If I refresh my browser, causing websocket to disconnect/reconnect, the old unit processes immediately exit. |
Correct. Unit should keep the application process running while WebSocket connections served by the process are opened. Unfortunately, there is a bug in Unit code, which makes established WebSocket connections hang if the listener removed. Please try this patch to fix the issue. |
That did not work. I am running 1.22.0. Let me know if I need to patch a newer version or HEAD. I have your example running: kelly@nkcdev11:~/download/nginx/unit-1.22.0.patched $ curl -X GET http://localhost:8000/config
} I hit this with a browser, thus establishing a web socket connection. I need the old version to shut down when I reconfigure. OR I need some way to know in my application code that reconfigure has happened so I can shut down web sockets. Otherwise old asgi_chat instances will never shut down. -K |
This is how it supposed to work. Unit keeps the process running to serve established WebSocket connections. The patch only fixes the functionality of these connections. There is an "application restart" feature (see Process Management ) introduced in 1.25.0. During restart, WebSocket connections are closed. |
I would suggest the following sequence for test and deployment using restart feature introduced in 1.25.0:
|
The new restart feature allows me to accomplish my goal. Thank you. |
Because the configuration values were read from the listener's configuration, an established WebSocket connection was unable to work properly (i. e. stuck) if the listener was removed. The correct source of configuration values is the request config joint. This is related to issue #581 on GitHub.
@krburkhart the event, that would help to gracefully resolve this situation was discussed here: django/asgiref#199 |
@VBart, I had not seen that, thanks. The lifespan.shutdown.notice event is exactly what I would like to see. However it appears to have been vetoed. Disappointing for me, however I'm reluctant to squander goodwill by beating a dead horse. Your restart functionality with my shenanigans is sufficient for me to achieve my goals. While not entirely in Unit's court, it would IMO be useful if the asgiref people tightened up the shutdown spec and uvicorn, daphne, hypercorn, unit implemented lifespan consistently. Thanks, -K |
I am running Django Channels under Unit 1.23.
If I have an ASGI application running with connected web sockets, that application does not shut down.
Is there a way from within my ASGI app to know that the Unit wants to shut down so that I can notify connected clients, clean up and let the new Unit instance take over?
I thought I might be able to use lifespan messages to manage this, but the lifespan shutdown message only occurs after all websockets have disconnected and it's too late to do anything. Perhaps if this message was sent immediately after listeners are removed rather than after all connections are closed?
Thank you,
-Kelly
The text was updated successfully, but these errors were encountered: