[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [libmicrohttpd] Support for zero-downtime deploys
From: |
Scott J. Goldman |
Subject: |
Re: [libmicrohttpd] Support for zero-downtime deploys |
Date: |
Thu, 25 Apr 2013 12:30:27 -0700 |
Rad! I'll try it out and get back to you.
On Apr 25, 2013, at 4:16 AM, Christian Grothoff <address@hidden> wrote:
> Dear Scott,
>
> I don't like the limitations of your patch, and I think I've come up with a
> much cleaner solution. The attached UNTESTED diff should apply cleanly
> against SVN HEAD. Please let me know if it works, and I would
> really appreciate a test case (or a few, for the different threading
> modes), as this does seem a bit convoluted and there might be corner
> cases I overlooked. And after all, the last thing you want for a
> zero-downtime deployment is crashing code ;-).
>
> Especially with a test, I can see this going into MHD relatively quickly ;-).
>
>
> Happy hacking!
>
> Christian
>
> On 04/25/2013 10:31 AM, Scott J. Goldman wrote:
>> 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
> <quiesce.diff>