Halt function to gracefully stop the app

[pfk84]

When using the builtin webserver I'd recommend having a halt function ($app->halt) as well to stop the builtin webserver from accepting new requests so that the app can be stopped after having served all current requests.

This is particulary useful wenn one has added signals to interrupt SIGINT, SIGUSR2 etc. so that tools like nodemon can gracefully restart the app if there has been an update.

What do you think? Or is there already a good way to do this?

[clue]

@pfk84 Excellent suggestion! And in fact precisely what I'm working on at the moment now that #136 is in! :)

The idea is to automatically add SIGINT and SIGTERM handlers and terminate gracefully by default. This way, you don't have to add any custom signal handlers or interface with any explicit APIs. On top of this, this means that CTRL + C and docker stop and others just work™.

[pfk84]

Great news, I'd definitely welcome an option to stop accepting new connections first and after a configurable timeout (in ms) pending connections get closed/loop stopped.

[pfk84]

I'm currently implementing an SSE endpoint and have the issue that if the socket is just closed, this not only leads to an error message in the browser console (ERR_INCOMPLETE_CHUNKED_ENCODING) which, granted is not too big of an issue, but I'd also like to be able to send a message to the clients with e.g. reconnect information etc. before shutting down.

Therefore, moving the code to close the socket & stop the loop into a dedicated $app->stop/halt function that one could manually call would still be appreciated as if I interrupt the signals myself this won't be done anymore...

[clue]

@pfk84 I'm not opposed to the idea, but I wonder how we would signal the connection is about to close so you can react in your consumer code? You may detect the close event on an outgoing response body stream, but at this point it's really too late to send some final message. What do you have in mind?

[pfk84]

Right now, I'm also hooking SIGINT and SIGTERM, thus the Framework X handler for gracefully shutting down never gets called and I don't have an option to gracefully close the http server socket because all I can do is to stop the main loop.

I'm doing this so I can go through all my SSE connections (well, broadcast stream actually :)) and send them a different retry time (the default is a longer interval so in case of server issues they don't get flooded, but in case of maintenance restarts I'd like to have the clients reconnect to a different server in a shorter time).

This is definitely a corner case and mainly optimization and maybe I could be switching to a custom signal that gets called beforehand just for this purpose in the future. On the other hand if there's a ->run() method I'd kinda also expect a ->halt() method... ;)

[SimonFrings]

@pfk84 Sounds like a useful addition but I'm not sure if a ->halt() method would be the answer here. This problem could also be resolved if:

1. We add a small window of time (maybe 1 second?) between receiving the signal and shutting down the server. This way we give all open connections the chance to resolve, while not allowing new connections to come in. There's also the possibility to send out the messages you talked about.

but I'd also like to be able to send a message to the clients with e.g. reconnect information etc. before shutting down.

2. You use some kind of serverless infrastructure. Your server will then only start running if connections come in and will keep it this way until all connections are handled. After that, the server will shut down until a new request comes in.