eidheim
commented
7 years ago Sorry for the late reply, but I'm not entirely sure what happens in Boost.Asio on SIGTERM. I would guess that the io_service is attempted to stop gracefully so that current read and write operations would finish, but you would have to double check this. I think I still would implement a handler to the kill signal and within this signal call server.stop(); server.io_service->reset(); server.io_service->run(); to make sure all the async operations finish. This will work since the acceptor will be shut down, so new requests will not be pushed to the io_service. Still, I would do my own tests here, and look into the Boost.Asio reference, since I'm not 100% sure.
edit: I added server.stop();
neil-freshdesk
I have used the server to implement an api for a service. I have read behind the scenes libasio uses a backlog queue size of 5 - not sure if this is true. I want to understand how the server will behave if a SIGTERM call is fired.
Lets say the listen system call was invoked with a backlog of 5. If a SIGTERM signal is fired on the process, what happens to the pending requests in the queue? Will the pending 5 requests be processed before the server shuts down, or will I need to write a signal handler for this.
If yes, how can I query how many requests are pending which need to be serviced before the server terminates itself.
SUMMARY :
Consider a scenario where the server is behind HAPROXY - and I have 4 such servers running on different ports. Lets say that I need to restart my servers periodically after updating some csv data files. If I fire a SIGTERM signal to the process, what happens to the items in the listen queue. If 4 requests were in the backlog and not processed what would happen to the end client who invoked the api call? Would it be simpler to try the api call in the client before they fail or should I write a signal handler to deal with this scenario.
Many Thanks for any inputs in advance.