Replying here as I was thinking about suggesting a go/vet check if the body is actually being closed.
What I realise now is, that closing the body is just as good as not closing it as long as one doesn't read it first. As for reading there is probably a trade-off on when actually reading is still faster than establishing a new connection, either in latency or just cpu cycles/ power consumption. Given that- I'm wondering if it weren't proper advise to just NOT care about closing the body unless you know for sure that you're interested in keep alives? Cheers, Andi On Saturday, July 7, 2018 at 7:16:56 AM UTC+2 time...@gmail.com wrote: > that's for sure. I has same issue, IF you don't close the body even you > don't care about that, the file descriptor won't close and lead to "too > many open file" error > > 在 2014年9月17日星期三 UTC+8下午3:28:34，Philippe Lafoucrière写道： > >> I had the same issue. I was not reading the body in most cases (only if >> there's an error, otherwise the body is an empty string on the distant API). >> I was leading to leaking open files on the server, so I confirm, you MUST >> close the body, even if you don't read it :) >> > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/c1ba134d-d6db-4252-917c-1d0e7ddde3bcn%40googlegroups.com.
