libmicrohttpd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[libmicrohttpd] Support for zero-downtime deploys


From: Scott J. Goldman
Subject: [libmicrohttpd] Support for zero-downtime deploys
Date: Thu, 25 Apr 2013 01:31:56 -0700

Hi.

Where I work, we do continuous deployment of services, so it's important to us 
to be able to be able to deploy new code and restart our services in a way that 
doesn't cause downtime. One of the ways we do that is by deploying daemons 
which can fork-exec themselves and inherit the listening socket. With a 
slightly modified libmicrohttpd, we implemented this functionality. It works 
like this:
1. send SIGUSR1 to the daemon
2. daemon fork-exec's a new version of itself, passing the fd# of the listening 
socket, and a status pipe via command-line args
3. new daemon initializes, starts accepting connections on the socket (with 
MHD_OPTION_LISTEN_SOCKET), and sends a message via the status pipe
4. old daemon operates normally until it gets the status message, and then 
stops accept()ing new connections, but continues processing old ones
5. old daemon finishes processing all remaining clients, and terminates

libmicrohttpd had nearly all the functionality we needed, except for having the 
"quiesce" functionality, to stop accept()'ing new connections, while continuing 
to process existing clients. I'm wondering if you would consider this feature 
for inclusion in your mainline version of the library. I've included a link to 
our patch below that is our rough attempt to hack in this functionality. I 
would be happy to revise it with your feedback.

https://gist.github.com/scottjg/5458005
https://gist.github.com/scottjg/5458005/raw/4ad505101f80485e24a6a2f1092f173706749df3/quiesce-api.patch

The main issue with the patch is that calling shutdown() on the listening 
socket is no longer acceptable in this mode. On Linux, calling shutdown() in 
the old daemon will prevent the new daemon from being able to accept() new 
clients. For our purposes we used the alternate pipe method to wake up the 
event loop, which appears to works fine.

Cheers,
-sjg


reply via email to

[Prev in Thread] Current Thread [Next in Thread]