Re: Zero-downtime HTTP server in Go

[Miki Tebeka]

You can do "zero down" with some load balancer. nginx, apache and many other have that feature.

You can also check out seamless ;)

On Thursday, March 21, 2013 5:05:17 PM UTC-7, Manuel Amador wrote:

We're researching using Go to build RESTful services.

One requirement we've been given is that any HTTP server we write must be able to provide what it's known as "zero downtime", that is, code reloads must not cause ongoing requests to be lost, and must not cause an outage window where the HTTP server is not accepting requests.

Another requirement is that the HTTP server must be able to be configured so it will listen on a UNIX socket, such that we don't need to worry about TCP port->service mappings.

We know that it's possible to do this because servers like Gunicorn and NginX (via fork() and passing FDs), so this factors in our decision for a platform, and right now it weighs against writing Go-based services.

So we've found some (albeit buggy) code that doesn't quite cut the mustard.  http://blog.nella.org/?p=879

What we're looking for is a contractor who will write a Go package for us, with a function which will do the following:

- substitute for http.ListenAndServe() such that we can use it in our Go web services like that,

- such that a UNIX signal sent to the program will cause it to fork a new program listening on the same socket, and exit the old one cleanly,

- the function should be usable from within a goweb or gorillaweb app,

- the function should be able to listen to UNIX sockets, and,

- of course, the exiting program should exit cleanly rather than abort ongoing requests.

Those are the requirements.  We can pay you in U.S. dollars or Bitcoin (your choice).

If this is not the appropriate forum for this type of request, please point me to the right forum.

[Devon H. O'Dell]

2013/3/21 Miki Tebeka <miki....@gmail.com>:

> You can do "zero down" with some load balancer. nginx, apache and many other
> have that feature.
> You can also check out seamless ;)

I knew it would be the first reply.

He "can't" (won't) do this. Anyway, he was very unhappy when, after
offering bitcoins to whoever could help, I suggested that IRC wasn't
the right medium for trying to find contract work (apparently that
means I called him a scammer and that I have no clue what I'm talking
about).

The code he was looking at using can occasionally get stuck when
accept blocks under the hood. Apparently this is unacceptable for him,
and coupled with the fact that the community (me) is so hostile
towards him, he will not be using Go.

--dho

> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Miki Tebeka]

In what way were you "hostile"? Or is it sarcasm?

[Andrew Gerrand]

First, this is a fine forum for soliciting Go contract work.

Second, I would suggest you investigate using a multi-process model where a group of public-facing HTTP servers proxy requests to a group of backends. The front ends could make regular "health check" requests to the back ends (a request that basically says "Are your running and accepting requests?"), and then only send user requests to healthy back ends.

The key advantage of this approach is scalability. When you need to move to a multi-machine or multi-service model, the work is already done for you.

It's relatively easy to write an HTTP "reverse proxy" like this in Go. This talk discusses a similar problem: http://talks.golang.org/2012/simple.slide

Andrew

[Kyle Lemons]

In addition to Andrew's suggestion about making a frontend, I am working on open-sourcing a library that can provide zero-downtime restarts.  Mine is similar in function to godoc.org/github.com/rcrowley/goagain though I think the API is much easier to use ;-).

[Manuel Amador]

I appreciate your advice and I already have this scaling model implemented for the frontend services.

Now I want a zero-downtime Go backend.

No, reconfiguring the frontend and reloading it twice every time a back end needs to be restarted (to swap old backends out and new backends in) is not an acceptable substitute. It also does not solve the problem that backends exiting will kill off any connections they are handling.

[Patrick Higgins]

I have implemented something like this, and encountered a bug while doing so and attached code implementing much of the idea to issue 4737. I did strip out as much as I could to make the bug easier to diagnose, but there's still a lot of the core left. Feel free to study the code. I have been planning to make a releasable package out of it, but have been swamped with non-Go work. Kyle Lemons will probably beat me to it.

[Andrew Gerrand]

On 22 March 2013 11:44, Manuel Amador <manuel...@aditazz.com> wrote:

I appreciate your advice and I already have this scaling model implemented for the frontend services.

Now I want a zero-downtime Go backend.

No, reconfiguring the frontend and reloading it twice every time a back end needs to be restarted (to swap old backends out and new backends in) is not an acceptable substitute. It also does not solve the problem that backends exiting will kill off any connections they are handling.

It's important to keep in mind that backend servers will die spontaneously, no matter how careful you are. You should design your systems with this in mind.

At Google, we do something like I described in my original mail. Upgrades of backend services are managed by gracefully shutting down the old backends (finishing off any inflight requests) while bringing up the new ones. The front ends are responsible for sending requests only to healthy back ends. This works very well. (It's hard to argue with Google's availability record!)

Andrew

[Roberto De Ioris]

> On 22 March 2013 11:44, Manuel Amador <manuel...@aditazz.com> wrote:
>
>> I appreciate your advice and I already have this scaling model
>> implemented
>> for the frontend services.
>>
>> Now I want a zero-downtime Go backend.
>>
>> No, reconfiguring the frontend and reloading it twice every time a back
>> end needs to be restarted (to swap old backends out and new backends in)
>> is
>> not an acceptable substitute. It also does not solve the problem that
>> backends exiting will kill off any connections they are handling.
>>
>

> It's important to keep in mind that backend servers *will* die

> spontaneously, no matter how careful you are. You should design your
> systems with this in mind.
>
> At Google, we do something like I described in my original mail. Upgrades
> of backend services are managed by gracefully shutting down the old
> backends (finishing off any inflight requests) while bringing up the new
> ones. The front ends are responsible for sending requests only to healthy
> back ends. This works very well. (It's hard to argue with Google's
> availability record!)
>
> Andrew
>
>

The uWSGI project now supports Go as a first class citizen.

Things like binary patching, hot-swapping of instances and tons of other
production tricks are available for free:

http://uwsgi-docs.readthedocs.org/en/latest/Go.html

the Zerg mode is what you can use to implement instance swapping (or
reinforcement) on the same machine:

http://uwsgi-docs.readthedocs.org/en/latest/Zerg.html

while the subscription system can be used for network-wide automatic scaling:

http://uwsgi-docs.readthedocs.org/en/latest/SubscriptionServer.html


--
Roberto De Ioris
http://unbit.it

[Manuel Amador]

Dear goers,

After I posted my request for a zero-downtime HTTP server on the #go-nuts IRC channel -- in a more informal manner -- then explained that we were willing to pay (Bitcoins or U.S. dollars) for the work, then explained (numerous times) that HTTP load balancing Go apps using a frontend -- while useful -- did not solve this specific problem or fit our requirements...

...Devon H. O'Dell (dho) proceeded to repeatedly insult me, deride what I was trying to do, question my professional competence, and insinuate repeatedly using sarcasm that I was trying to scam people (on the basis that I suggested Bitcoin as one form of payment).  Then he proceeded to dog everyone else I was peacefully interacting with, to get them to stop helping me.  In the interest of full disclosure, after repeated verbal abuse from Devon, I called him an asshole once for being verbally abusive, and then added him to my ignore list.

I don't know about you guys, but where I come from, Devon's behavior is simply unacceptable.  Now, as I can see, he has joined this list to continue his smears against me (already started by falsely portraying what happened in #go-nuts, which can be fact-checked by anyone who has access to the channel logs).  He could have chosen to stay out of this, consistent with his repeatedly stated belief that zero-downtime servers in Go "cannot be done", but he did not.  I suspect he will try here to accomplish the same "derail the conversation" sabotage he accomplished in #go-nuts -- he has already started by meddling himself into this conversation with a personal matter he should have handled off-list.

I am less than happy about this.

He is correct in one thing, though: toxic people like him play an enormous factor in our decision to choose Go for the following years' projects.  One can be an excellent engineer, but being an excellent person comes first.  A Go "community member" ("regular", as they called him) who openly mocks and attacks someone for him posting a conceptually simple request, is not an excellent person, by any stretch of the expression.

One good thing comes out of this though -- at least now I know Devon's full name, which affords me the possibility never to associate with him, and to forewarn others about his tendency toward verbal abuse.

I appreciate if further conversation about this topic was kept strictly off-list.  Let's go back to solving the zero-downtime problem with Go.  Thank you very much for your cooperation and very, very helpful responses.

[Manuel Amador]

Kyle,

This is PHENOMENAL.

I note that your code has a number of TCPListener interfaces.  How feasible is it to rewrite it to use a more generic Listener interface, so it will work with UNIX sockets?  That eliminates local access to the Go HTTP server, and eases the problem of mapping a constrained space of port numbers to backend servers in my frontend.

[Manuel Amador]

I was looking at the example:

https://github.com/rcrowley/goagain/blob/master/cmd/goagain-example/goagain-example.go

Serve gets called when it's time to accept the socket.

I guess my question is: how do we plug this into a Web framework like Gorilla Web or goweb?  They use the default ListenAndServe...

On Fri, Mar 22, 2013 at 12:35 PM, <c...@aditazz.com> wrote:

So it should be a fairly trivial task to take your goagain code and make it look at sockets instead of ports, right?  Let me know if you foresee any pitfalls...

On Friday, March 22, 2013 11:18:47 AM UTC-7, Kyle Lemons wrote:

[Devon H. O'Dell]

Your account here also false, and the only reason I'm responding is
that your post here approaches slander. I am a long-time contributor
to the Go project and have helped many, many people learn Go. I have
not verbally insulted you in any public forum in which your name has
been tied, nor have I said anything publicly that calls your
credibility into account.

2013/3/22 Manuel Amador <manuel...@aditazz.com>:

> Dear goers,
>
> After I posted my request for a zero-downtime HTTP server on the #go-nuts
> IRC channel -- in a more informal manner -- then explained that we were
> willing to pay (Bitcoins or U.S. dollars) for the work, then explained
> (numerous times) that HTTP load balancing Go apps using a frontend -- while
> useful -- did not solve this specific problem or fit our requirements...

You denied that it worked, and refused multiple times to allow anyone
to explain why it would work for your situation. You also refused to
accept that CDNs that provide shielding services would also solve this
problem without you needing to change your infrastructure as well.
Multiple people suggested this was the correct approach on IRC, and
multiple people have suggested it is the correct approach here, as
well.

Andrew Gerrand puts it best: "It's important to keep in mind that
backend servers will die spontaneously, no matter how careful you are.
You should design your systems with this in mind." It was with this in
mind that I said what you wanted to do was "impossible."

> ...Devon H. O'Dell (dho) proceeded to repeatedly insult me, deride what I
> was trying to do, question my professional competence, and insinuate
> repeatedly using sarcasm that I was trying to scam people (on the basis that
> I suggested Bitcoin as one form of payment). Then he proceeded to dog

I did no such thing. The thing I said that you took offense to was:

19:32 < dho> I'm going to recommend that nobody work with you.
Bitcoins are not real money whether or not people ascribe value to
them. Additionally, you've provided no guarantee that you can or will
pay.

I have taken up contracts on IRC before, in my younger, more naïve
years. People don't pay, frequently. This statement does not call you
a scammer, but it did provide you with an opportunity to prove that
you would pay a contract (ignoring the fact that IRC is anonymous and
not the right medium for soliciting work). You then stated:

19:33 < Rudd-XXX> dho, you're accusing me of trying to scam people.
That's a really horrible thing to say. I don't appreciate your
anti-help.

I replied:

19:34 < dho> I am not in fact accusing you of anything other than not
providing any guarantees that you can pay or that you will.
19:34 < Rudd-XXX> just because I am not willing to implement what you
suggest, does not give you license to attack me personally and
discredit my requests for a contractor. That's horribly
unprofessional and hateful on your part.
19:34 < dho> I have the right to say what I would like.
19:34 < dho> in fact.
19:35 < dho> And on top of it all, conducting business on IRC is a bad idea.
19:35 < Rudd-XXX> dho, Yes. You have the right to be a horrible person.

If anything, you are the verbally abusive person here. And now you are
slandering me publicly on an email list of a project that I have been
involved with since it was publicly released. I do have the full log
of this conversation, and I am happy to provide it to anyone who
cares, because I was not repeatedly abusive towards you and I did not
call you a scammer.

> everyone else I was peacefully interacting with, to get them to stop helping
> me. In the interest of full disclosure, after repeated verbal abuse from
> Devon, I called him an asshole once for being verbally abusive, and then
> added him to my ignore list.

Repeated verbal abuse from me:

19:35 < Rudd-XXX> aandy, we are already running a frontend proxy. I
don't want to add another one.
19:35 < dho> You *do not run another one*
19:35 < dho> for FUCKS sake
19:35 < dho> are you dense?
19:37 < dho> Rudd-XXX: stop asking people to write a hacky, crap
solution to a problem that already has a simple one you refuse to
implement.
19:38 < Rudd-XXX> Problem two is that, during the brief time that the
backend server is restarting, nginx returns gateway error to the
clients attempting to make a request.
19:39 < dho> Then you did it wrong.

After this, I said *nothing* to Mr. Amador, and as far as I can tell,
the only way (through the whole conversation) I was verbally abusive
was in asking him if he was dense. After this, he said:

19:41 < Rudd-XXX> /ignore dho

I was plenty verbally abusive after that. But he was ignoring me, so
how could he know? After that, I did continue to warn people of the
dangers of doing paid work for people over IRC. People did end up
helping him with his problem to the extent that it can be solved. And
he got a solution (that was not good enough for him) for free.

> I don't know about you guys, but where I come from, Devon's behavior is
> simply unacceptable. Now, as I can see, he has joined this list to continue

I've been on this list since I contributed the FreeBSD port in 2009.

> his smears against me (already started by falsely portraying what happened
> in #go-nuts, which can be fact-checked by anyone who has access to the
> channel logs). He could have chosen to stay out of this, consistent with

And you have falsely portrayed what I did, except now you have done it
in public on a forum I frequent and can be used by future employers. I
would stay out of this, but you have absolutely forced my hand here.
(My apologies to everyone on the list, I really f*cking hate ML
drama.)

> his repeatedly stated belief that zero-downtime servers in Go "cannot be
> done", but he did not. I suspect he will try here to accomplish the same

Based on your requirement that it needs to be able to survive signals, it can't.

> "derail the conversation" sabotage he accomplished in #go-nuts -- he has
> already started by meddling himself into this conversation with a personal
> matter he should have handled off-list.

And now you're doing the same, except going 139851298 times farther,
in a public place, and because of your own false claims, you are
absolutely slandering me.

> I am less than happy about this.

That's a riot.

> He is correct in one thing, though: toxic people like him play an enormous
> factor in our decision to choose Go for the following years' projects. One
> can be an excellent engineer, but being an excellent person comes first. A
> Go "community member" ("regular", as they called him) who openly mocks and
> attacks someone for him posting a conceptually simple request, is not an
> excellent person, by any stretch of the expression.

You were badgering people to work:

19:51 < Rudd-XXX> AeroNotix, yes I have political problems, now can
you please either offer to work for money or stop telling me what's
wrong with the world?

You made several of these sorts of comments, in which you told people
to either stop giving you advice, or accept a contract to work with
you. You do not own the community and the basis that you have money to
give people to help you with a problem does NOT entitle you to tell
people to shut up. The above quote, again, is not the only time you
did this. So I "mocked" you for posting a "conceptually simple
request?" No. I mocked you for acting entitled to a response because
you had bitcoins to give out.

And, for the record, you said nothing about US dollars until I
mentioned that payment in bitcoins is insulting to professionals.

> One good thing comes out of this though -- at least now I know Devon's full
> name, which affords me the possibility never to associate with him, and to
> forewarn others about his tendency toward verbal abuse.
>
> I appreciate if further conversation about this topic was kept strictly
> off-list. Let's go back to solving the zero-downtime problem with Go.
> Thank you very much for your cooperation and very, very helpful responses.

So would I. Except you've now slandered me, and I have to defend
myself. You could have chosen to email me privately with your
grievances.

--dho

[Andrew Gerrand]

I ask both parties involved here to please refrain from playing this out on this public mailing list.

In the interests of full disclosure, the IRC logs are available publicly (this link leads to what I believe is Manuel's first message):

  https://botbot.me/freenode/go-nuts/msg/2367541/

Anyone interested can read the logs and draw their own conclusions. I doubt it is worth your time, though.

I repeat my appeal: this is not the venue to air personal disagreements. Please do not continue this discussion here.

Andrew

[Manuel Amador]

Thank you for this, Andrew.  I really do appreciate it.

[Steve McCoy]

On Friday, March 22, 2013 1:01:32 PM UTC-4, Andrew Gerrand wrote:

It's relatively easy to write an HTTP "reverse proxy" like this in Go. This talk discusses a similar problem: http://talks.golang.org/2012/simple.slide

Andrew

Sweet, I never saw this one. Thanks! 

[Manuel Amador]

This is amazing.  Thanks!

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/41TPj4PWBI8/unsubscribe?hl=en-US.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.

[Anthony Martin]

Devon is a known, serial Plan 9 user.

Every Plan 9 user is an asshole. All four of us.

Anthony

[Manuel Amador]

Goagain is amazing, and we are successfully running it with UNIX sockets (we plan to provide a proper pull request adding this feature)

HOWEVER, https://github.com/rcrowley/goagain/issues/5

We just filed a bug to try and collaborate with rcrowley and fix the issue.

[Manuel Amador]

We have made significant progress with goagain, significant enough that I can say:

- We will be done adding UNIX socket support to it very soon.

- We have made the program linger after being signaled and forking its child, processing any slow ongoing requests, but not accepting new ones (in turn, delegating the accept of new connections to the child) 

- We have eliminated the issue whereby the child would kill the parent, aborting ongoing requests

We hope to submit code upstream soon.

[Manuel Amador]

So here is the code.  We cracked the problem completely.  Proof that one can write a Go HTTP server that gracefully upgrades itself with literal zero downtime.

https://github.com/rcrowley/goagain/pull/7

Thank you all who gave useful pointers.  You were helpful beyond belief.  One small bug remains (dup'd FDs), not hard to fix.  We'll collaborate with rcrowley to diagnose it and fix it.

As for the small contingent of people (you know who you are) who insisted "can't be done" and that I was "incompetent" and "a whiny ass": the code above says you were wrong.

Thanks again, guys.

[Péter Szilágyi]

I'm sorry, but I have to disagree with you. Really simple use cases: your computer hardware fails, or a router crashes, or there's a power outage, etc. There's no software in the world running on a single node that can save you. There will be data lost, there will be connections dropped. I hope you agree with the reasoning.

But if there's a chance to lose a node, you need higher level logic to "program around" failures. But if you've got the higher failure handling in place, you don't need the complicated lower ones any more.

So my conclusion is: yes, you can write zero downtime programs, but no, they do not solve the problem.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

[Manuel Amador]

I get the feeling that you and I are talking about different problems.

I was referring to the problem of a zero downtime upgrade and restart of an HTTP backend, as explicitly defined above by me and others.

You seem to be talking about the general problem of high availability, which is larger in scope.

Now, I am aware that there are other problems that need solving for a comprehensive solution, like the problem of high availability, the problem of handling software and hardware failures, et cetera.

Making a Go program that can restart itself without losing connections is not a solution to those other problems. I never said it was nor would I suggest that, ever.

Let's get some common ground in terminology before criticizing each other's ideas, proposals and code.

Have a great day! :-)

[Steve Phillips]

I think something like Falcore is what you're looking for: https://github.com/ngmoco/falcore

Core feature: "Hot restart hooks for zero-downtime deploys"

I saw a live demo of this in action at a GoSF Meetup last year.  Surprised no one has mentioned falcore yet.

Hope this helps!

--Steve

[Kyle Lemons]

On Fri, Mar 22, 2013 at 12:30 PM, Manuel Amador <manuel...@aditazz.com> wrote:

Kyle,

This is PHENOMENAL.

I note that your code has a number of TCPListener interfaces.  How feasible is it to rewrite it to use a more generic Listener interface, so it will work with UNIX sockets?  That eliminates local access to the Go HTTP server, and eases the problem of mapping a constrained space of port numbers to backend servers in my frontend.

Lest there be any confusion, I am not the author of goagain, and I can't really speak much to its implementation, I only know it through his blog post on the subject.

My library (still waiting on one more approval...) is a generic listener-based model.  I use it to handle passing listeners for both http, https, and net listeners to subprocesses.  It integrates nicely with flags, however, and also has some other handy daemon properties (privilege dropping, etc) that I needed.  It uses a similar mechanism to what rcrowley describes in his blog post to trace living connections so that the "old" binary knows when to exit.

[Rory McGuire]

+1

[Manuel Amador]

Falcore has the same problem that our server has -- it leaks sockets on restart.

https://github.com/Rudd-O/goagain

We've rewritten it to work with UNIX sockets.  If anyone here is interested in making it compatible with both TCP and UNIX sockets, that'd be great.

[ftrvxmtrx]

Somewhat related, though only a small (and low-level) part of what you want to get: http://godoc.org/github.com/goerlang/fd

[Naitik Shah]

I've written something that I think satisfies most of your goals:

https://github.com/daaku/go.grace

The exception is the "listen on a socket" part, which you can build
using the underlying libraries (the basic abstraction involves a File
based listener, so a UNIX socket also qualifies).


-Naitik

> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>



--

-Naitik

[atomly]

go-web looks very nice!  

:: atomly ::

[ ato...@atomly.com : www.atomly.com  : http://blog.atomly.com/ ...
[ atomiq records : new york city : +1.347.692.8661 ...
[ e-mail atomly-new...@atomly.com for atomly info and updates ...

On Tue, Mar 26, 2013 at 12:35 AM, Alexandre Fiori <fio...@gmail.com> wrote:

Hi Manuel,

I've been playing with Go's net/http and ended up with a small patch that adds support for things I often need on web applications.

These include: Unix sockets, ability to automatically use the contents of X-Forwarded-For as the Request.RemoteAddr, logging, and a few other things.

freegeoip.net has been running on it for a couple of weeks and so far no problems at all. I'll probably blog about it when possible.

https://github.com/fiorix/go-web

Cheers

[Fatih Arslan]

Any improvements on that? I wanted to use goagain but I'm using several listeners and I had to hack on goagain to support it. Howeve the way it handles file descriptors made my life hard. Did you open sourced your code or are you still waiting? 

Thanks in advance

Regards

On Friday, March 22, 2013 8:18:47 PM UTC+2, Kyle Lemons wrote:

In addition to Andrew's suggestion about making a frontend, I am working on open-sourcing a library that can provide zero-downtime restarts.  Mine is similar in function to godoc.org/github.com/rcrowley/goagain though I think the API is much easier to use ;-).

On Thu, Mar 21, 2013 at 5:05 PM, Manuel Amador <manuel...@aditazz.com> wrote:

We're researching using Go to build RESTful services.

One requirement we've been given is that any HTTP server we write must be able to provide what it's known as "zero downtime", that is, code reloads must not cause ongoing requests to be lost, and must not cause an outage window where the HTTP server is not accepting requests.

Another requirement is that the HTTP server must be able to be configured so it will listen on a UNIX socket, such that we don't need to worry about TCP port->service mappings.

We know that it's possible to do this because servers like Gunicorn and NginX (via fork() and passing FDs), so this factors in our decision for a platform, and right now it weighs against writing Go-based services.

So we've found some (albeit buggy) code that doesn't quite cut the mustard.  http://blog.nella.org/?p=879

What we're looking for is a contractor who will write a Go package for us, with a function which will do the following:

- substitute for http.ListenAndServe() such that we can use it in our Go web services like that,

- such that a UNIX signal sent to the program will cause it to fork a new program listening on the same socket, and exit the old one cleanly,

- the function should be usable from within a goweb or gorillaweb app,

- the function should be able to listen to UNIX sockets, and,

- of course, the exiting program should exit cleanly rather than abort ongoing requests.

Those are the requirements.  We can pay you in U.S. dollars or Bitcoin (your choice).

If this is not the appropriate forum for this type of request, please point me to the right forum.

--

[Kyle Lemons]

On Tue, Jun 18, 2013 at 7:01 AM, Fatih Arslan <ftha...@gmail.com> wrote:

Any improvements on that? I wanted to use goagain but I'm using several listeners and I had to hack on goagain to support it. Howeve the way it handles file descriptors made my life hard. Did you open sourced your code or are you still waiting? 

Hmm; I admit that this fell off my radar.  I haven't gotten final notice of approval yet, but let me look into it again.  It has support for lots of listeners, so hopefully it can help you once I get it out the door.

[Manuel Amador]

We will open source everything very shortly :-) we have come up with a mechanism that beats the previous FD passing and is compatible with the way systemd and upstart like to supervise services running "in the foreground".

[Reck Hou]

Hi Manuel:

Your requirements exactly meet what we are doing now. We are developing a zero-downtime daemon framework written by Go, it's almost done but still need some work for a release version. It supports TCP/HTTP/FCGI(Unix socket), and exactly meet what you need. Also configurable that users shouldn't need 

Glad to hear you have implemented your own daemon, hope we can have a further discussion about this.

Regards

Reck

[John Doe]

go get code.google.com/p/vitess/go/umgmt
пятница, 22 марта 2013 г., 2:05:17 UTC+2 пользователь Manuel Amador написал:

[swh...@fitstar.com]

Falcore does what you're asking for and has been working in production for more than a year.  The hot_restart example shows how to hook into the lifecycle to do zero-downtime deploys.

http://github.com/fitstar/falcore

Scott

On Thursday, March 21, 2013 5:05:17 PM UTC-7, Manuel Amador wrote: