Hi Egon, Thanks for that. It seems to implement the same requirements as implemented in my example, although I prefer my implementation as it doesn't require a sleep/loop.
The implementation I provided in the original email, with the exception of the bug that Augusto pointed out, works as desired. The question was not how to implement these requirements, but how to validate them with a test cleanly. Unfortunately it doesn't seem that I was clear in my original post since most people are focusing on the implementation of the requirements. Thanks again for your effort in this--apologies for miscommunication the original question. Evan On Tue, 13 Sep 2016 at 14:48 Egon <egonel...@gmail.com> wrote: > > > 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> 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. >> >> >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- > 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.
