Seeing "cannot assign requested address" errors with http.Client

2,508 views
Skip to first unread message

Eli Janssen

unread,
May 27, 2013, 12:17:48 AM5/27/13
to golan...@googlegroups.com
Nuts,

I am running into an issue, hopefully stemming from me doing something wrong.
I have reproduced/abstracted the issue from a larger app: http://play.golang.org/p/GkS5iM3y1y

What I would expect, is that 10 goroutines are launched, and after a short while there would be a pool of keepalive'd connections to the localhost web server, and that the http clients would re-use conns from that pool.

What I am seeing instead, is after a short while:

2013/05/27 04:03:24 Err: Get http://127.0.0.1/: dial tcp 127.0.0.1:80: cannot assign requested address

The box itself indeed appears to be running out of connections. The output of `ss` shows over 55k conns (nearly all in time-wait state).
The local webserver is nginx, with keepalive supported. Go version is "go version go1.1 linux/amd64"

Request response (captured with ngrep):

GET / HTTP/1.1.
Host: 127.0.0.1.
User-Agent: Go 1.1 package http.
Accept-Encoding: gzip.

Server: nginx.
Date: Mon, 27 May 2013 04:13:00 GMT.
Content-Type: text/html; charset=utf-8.
Content-Length: 61.
Last-Modified: Mon, 27 May 2013 04:12:41 GMT.
Connection: keep-alive.
Accept-Ranges: bytes.
.
<html>
<body>
<div align="center">test</div>
</body>
</html>


What am I missing? Any ideas?

Thanks.

Eli Janssen

unread,
May 27, 2013, 12:55:12 AM5/27/13
to golan...@googlegroups.com
Here is a slightly cleaned up version that still behaves the same, but removes some "code noise":
http://play.golang.org/p/bD-A0MzdjR

If I start it with env GOMAXPROCS=1 it still bombs out, but it seems to take a bit (1 second maybe?) longer to do so.
The box has 8 cores, and I have been running the same code with GOMAXPROCS=4.

Eli Janssen

unread,
May 27, 2013, 12:58:57 AM5/27/13
to golan...@googlegroups.com
I wonder if I am bumping into this:

https://code.google.com/p/go/source/detail?r=d4e1ec84876c0f5611ab86a03826da14b866efb2&name=release-branch.go1.1&path=/src/pkg/net/http/transport.go

"This shifts the burden onto clients to read their whole response
bodies if they want the advantage of reusing TCP connections."

I will try reading the entirety of the response and see if that resolves my issue.

Eli Janssen

unread,
May 27, 2013, 1:05:03 AM5/27/13
to golan...@googlegroups.com
Indeed, I just needed to read all the response body.
Working great now. *sigh*
Reply all
Reply to author
Forward
0 new messages