On Tuesday, April 18, 2017 at 8:19:06 AM UTC-7, Peter Mogensen wrote:
>
> > and even if one was
> > still open, I'm making a new http.Client object, too!
>
> Yes. But you don't make a new Transport.
> Both your clients use DefaultTransport - which has the connection pool.
>
> /Peter
>
>
Bingo.
On 2017-04-18 17:08, Ken Simon wrote:
Yes that's very strange. My impression was that net.Listener.Close()
would actually sever the running connections...
It won't.
That's why Go 1.8 has Server.Close()
and even if one was
still open, I'm making a new http.Client object, too!
Yes. But yo
On 2017-04-18 17:00, Ken Simon wrote:
net/http.Server.Close() only exists in golang 1.8... I'm stuck in 1.7
right now so I can't use that.
No, but you can do something equivalent with either a connection manager
like in the various "graceful" libraries or simply (as also suggested)
disable
On Tuesday, April 18, 2017 at 5:51:40 AM UTC-7, Yuwei Ba wrote:
>
> Disabling the HTTP connection keep-alive may help for this situation by
> calling: `srv.SetKeepAlivesEnabled(false)` and get the expected output
> **sometimes**
>
> $ go run a.go
> In handler wrapper, f = 0xc4200111a0
> 1
> In ha
On Monday, April 17, 2017 at 10:30:43 PM UTC-7, Peter Mogensen wrote:
>
> However... If you call net/http.Server.Close() between the two calls you
> get the expected result... which indicates you might be struggling with
> the client side connection pool still having a keepalive HTTP connection
Disabling the HTTP connection keep-alive may help for this situation by
calling: `srv.SetKeepAlivesEnabled(false)` and get the expected output
**sometimes**
$ go run a.go
In handler wrapper, f = 0xc4200111a0
1
In handler wrapper, f = 0xc4200111a8
2
Though, it’s strange that you’ll still need t
On 2017-04-18 07:18, Peter Mogensen wrote:
On 2017-04-18 05:48, Ken Simon wrote:
go srv.Serve(l)
Have you tried check the error return value here?
Sorry... I was a bit too quick. That error shows accept error on close
as its supposed to.
However... If you call net/http.Server.Close()
On 2017-04-18 05:48, Ken Simon wrote:
go srv.Serve(l)
Have you tried check the error return value here?
/Peter
--
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
Hello golang-nuts!
I have some code that creates a short-lived HTTP server, and I'm trying to
write tests for it. I'm hitting a case where HTTP handlers seem to stick
around even though I'm creating a brand new `http.ServeMux`, `http.Server`,
and `net.Listener` objects. How do I get rid of ol