On Wednesday, 14 September 2016 00:18:26 UTC+3, Evan Digby wrote: > > Hi Egon, > > My requirements are more simple than a graceful http shutdown. I simply > require that everything that enters the RLock completes to RUnlock. > Accepted requests, or even calls to servehttp can die without issue as long > as they haven't entered the processing in the RLock. >
In that case https://play.golang.org/p/RiFEbQvytP. *Ps. Still tired, may contain bugs.* > If the server crashes we have ways to deal with that, but it's a more > DevOps-y process. Recovering from logging, etc.,and should be an edge case > that I'm not worried about handling in code. > > If the handler gets stuck in a loop, we will see that in our logging. I > don't want the server to die in that case. I want it to keep retrying (we > have exponential backoff) and informing us via structured logging of what's > going on. If it's an unanticipated loop/block, then there will be a manual > investigation into the server's state before we manually kill the process. > At that point it becomes similar to the last point, except easier because > we already know the state the message was in. > > In our use case we will always exit shortly after a close. It's safe to > assume the process will die after close returns. > > Thanks again, > > Evan > > On Tue, 13 Sep 2016 at 14:08 Egon <egon...@gmail.com <javascript:>> wrote: > >> On Tuesday, 13 September 2016 23:31:55 UTC+3, Evan Digby wrote: >>> >>> Hi John/Egon/Augusto, >>> >>> I should point out is that all we need to guarantee (barring abnormal >>> termination of course) is that once a task starts processing, it finishes. >>> Partially processed messages are bad, but http requests that don't result >>> in a message being processed at all are okay. >>> >>> We don't need to guarantee that the result of every Accept in the HTTP >>> server results in a processed message. We handle this on the OPS side by >>> ensuring we stop sending requests to that instance before terminating the >>> process. We just want to make sure, at that point, that the messages which >>> did make it to the handler are flushed. >>> >>> So the case where: >>> >>> h.Handle(...) <-- gets past the closed channel check, calls go ..., butthe >>> goroutine doesn't execute yet. >>> h.Close() <-- closes the close channel, Locks and Unlocks,returns. >>> ...now the goroutine executes and acquires the read lock. >>> >>> We actually don't care if "Handle" completes in this example. We only >>> care if that our task handler starts processing a message that it completes >>> the processing. >>> >> >> How do you actually ensure that it completes processing without hooking >> into Server? I.e. that buffers and sockets get properly flushed? >> >> Let's take a step back and what are the properties that you need -- >> >> I assume it's just graceful shutdown where all the pending ServeHTTP >> requests have been processed? >> >> What should happen when the server crashes -- is it vital for those >> requests to be processed, once they have been accepted? >> >> What should happen when one handler gets stuck in an infinite wait/loop? >> >> Does the "Close" returning mean you exit main or does hpw does the >> process termination depend on it? Or is it just another goroutine that is >> terminating not the whole process? >> >> + Egon >> >> -- >> 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/jh-nvt9ukBg/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> golang-nuts...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
