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.
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 <egonel...@gmail.com> 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+unsubscr...@googlegroups.com. > 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.
