On Sun, Sep 17, 2017 at 12:46 PM Steven Lee <kyn...@gmail.com> wrote:
> Thank you Silviu, that seems to work. > > Do you know exactly why it flakes? what is racing? just for me to have an > understanding of why this happens > > It is somewhat common to use the TCP window as a feedback mechanism to the server. If you can't process the body streamed to you fast enough, then the TCP window will fill and the server will stop sending. The alternative--empty the buffer in the kernel at the earliest--can lead to memory spikes in your program if you request large bodies in a short amount of time. In my experience, you should aim for sustained memory load rather than spiky memory load if you can. What likely happens is that the http client ends up in a state where it knows the status code of the request, but it hasn't yet read all of the body. Then the cancel arrives on the context. In this case, we abort the body read. It can be a half read, or perhaps we have not yet pulled anything from the body into the Go process from the kernels buffer. One reason for this behavior may be that many HTTP requests have no body, so you end up with code which is more complex if you need to cater for this and the context at the same time. Silviu already wrote what I would do to alleviate 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
