I’m against graceful shutdowns. The reason is that the client has to be able to handle a hard disconnect in any case, so might as well design it to handle it well, so no graceful shutdown is needed. Short-lived connections, always-consistent state, journaling, crash-only-software… There are plenty of techniques for handling hard shutdowns, use them instead of adding server code to mitigate client’s failures of error handling.
It’s true that you need to be able to handle hard disconnects, but sometimes a graceful shutdown will give a better experience than a hard one is capable of. E.g. “close all connections, flush, then shutdown” might avoid an expensive “restore from journal” when you next start up.
Yes, a few simple shutdown notifications without waiting for feedback is a reasonable thing to do. No waiting for replies, no grace periods. Maybe wait a second or two before cutting the power, if you are in charge of powering the clients and a shutdown means power off.
I’m against graceful shutdowns. The reason is that the client has to be able to handle a hard disconnect in any case, so might as well design it to handle it well, so no graceful shutdown is needed. Short-lived connections, always-consistent state, journaling, crash-only-software… There are plenty of techniques for handling hard shutdowns, use them instead of adding server code to mitigate client’s failures of error handling.
It’s true that you need to be able to handle hard disconnects, but sometimes a graceful shutdown will give a better experience than a hard one is capable of. E.g. “close all connections, flush, then shutdown” might avoid an expensive “restore from journal” when you next start up.
Yes, a few simple shutdown notifications without waiting for feedback is a reasonable thing to do. No waiting for replies, no grace periods. Maybe wait a second or two before cutting the power, if you are in charge of powering the clients and a shutdown means power off.