Re: [go-nuts] http.Server handlers seem to stick around forever

2017-04-18 Thread Ken Simon
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.

Re: [go-nuts] http.Server handlers seem to stick around forever

2017-04-18 Thread Peter Mogensen
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

Re: [go-nuts] http.Server handlers seem to stick around forever

2017-04-18 Thread Peter Mogensen
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

Re: [go-nuts] http.Server handlers seem to stick around forever

2017-04-18 Thread Ken Simon
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

Re: [go-nuts] http.Server handlers seem to stick around forever

2017-04-18 Thread Ken Simon
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

Re: [go-nuts] http.Server handlers seem to stick around forever

2017-04-18 Thread Yuwei Ba
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

Re: [go-nuts] http.Server handlers seem to stick around forever

2017-04-17 Thread Peter Mogensen
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()

Re: [go-nuts] http.Server handlers seem to stick around forever

2017-04-17 Thread Peter Mogensen
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

[go-nuts] http.Server handlers seem to stick around forever

2017-04-17 Thread Ken Simon
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