Comment 1:

Can you see any event which related to this issue in windows 
event viewer or something similar? I guess it would be help.

Comment 2:

Also please take a look at issue #3219 which describes 
my blunder. I feel something like get lost in the forest 
of Windows.

Comment 3:

I am not network expert, so ... :-)
"The specified network name is no longer available" have name of ERROR_NETNAME_DELETED.
Google for "AcceptEx ERROR_NETNAME_DELETED", maybe some of it apply to your case. As far
as Go concerns, I can't see any problem. net package calls AcceptEx to receive next
connection and the call fails with ERROR_NETNAME_DELETED, means someone connected, but
we could not established connection for one reason or the other. As you said, it could
be anything - bug in software, faulty hardware.
I can't reproduce it here on my computer.
Alex

Comment 4:

I will try to check for more specific test cases today. It could be something related to
my environment, but I don't want to risk not reporting an issue just in case something
crept in recently - especially with Go 1 nearly done.

Comment 5:

Additional findings. I believe the error is caused by exhausting sockets on Windows
(which isn't that hard to do). I have another program (which unfortunately I can't share
in its entirety) that uses 50 goroutines to post files to this server - using
client.Do() as shown in the Go example code, and using the default Transport object. It
also sets Request.Close to false (just in case). In the past, it seemed like keep-alives
limited the total connections to around 50. In 2012-03-04, the connections don't seem to
be reused anymore. I know there were recent changes to the net/http package relating to
proxies and keep-alives, but I haven't identified a bug yet, just this symptom which I
think is a real problem.
The basic file posting loop is at http://pastie.org/3555622 - in older versions of Go I
had tested the connection behavior pretty thoroughly.

Comment 6:

While it does not error out, running my test on Ubuntu Linux also generates thousands of
TIME_WAIT connections, indicating the same problem.

Comment 7:

Ok, maybe this is by design but I didn't notice it before. If I use my own Transport,
like:
var tr = &http.Transport{DisableKeepAlives: false, MaxIdleConnsPerHost: 50}
Then connections are far more likely to get reused, and you don't run out. This is
certainly helpful when heavy load is involved. I can't imagine how I didn't run into
this when I originally coded it under go 60.3, but it seems to make sense according to
net/http docs.

Comment 8:

Labels changed: added priority-later, removed priority-triage.

Comment 9:

After a reboot, initializing a Transport for my app (which posts a lot of stuff to the
same place and needs more idle connections available), and additional tests on Windows
and Linux - I am not recreating the issue anymore.
This can probably be closed.

Comment 10:

Status changed to Retracted.

Comment 11 by jp@webmaster.ms:

I have this issue. 
Windows 2008 Server
Go binary distribution from the download page (go1.0.1.windows-amd64.zip)
http server panics with "AcceptEx:The specified network name is no longer available"
after few hours of working

Comment 12 by jp@webmaster.ms:

w.Header().Set("Connection", "close") helps but degrades performance
Transport seems not applicable to a server app

Comment 13 by webmaster@webmaster.ms:

I solved it by compiling my program with 8g instead of 6g.