Almost 3 years later... I seem to be having the same issue you were having.
I have a worker pool, and each concurrent worker has its own client /
transport.
I do this because each transport/dialer has different proxy settings, and
there seemed to be no other way to circumvent this, such as passing a
custom dialer to the same, global client/transport combo.
After having read your article, I've went through my code. So far I have
checked the following:
1. No "keep-alive" set.
2. I've been running myTransport.CloseIdleConnections() every 10
seconds, for each worker's transport.
Here is my transport config:
myTransport := &http.Transport {
IdleConnTimeout: time.Second * 15,
TLSHandshakeTimeout: time.Second * 30,
MaxIdleConns: 1,
}
Anything else I may be missing?
Thanks.
On Monday, December 14, 2015 at 11:56:32 AM UTC-7, Sander van Harmelen
wrote:
>
> > While the http.Client itself isn't as big an issue, you will want to
> > pair each transport with its own Client so that you aren't changing
> > the Transport field while other calls are being made.
>
> That was indeed what I was thinking of :) Check… Again thanks for the
> feedback and I’ll go along this route then.
>
> Cheers,
>
> Sander
>
>
> On 14 Dec 2015, at 19:52: 50, James Bardin <j.ba...@gmail.com
> <javascript:>> wrote:
>
> On Mon, Dec 14, 2015 at 1:40 PM, Sander van Harmelen <san...@xanzy.io
> <javascript:>> wrote:
> > Check… So would creating the transport without a keepalive fix/change
> this?
> >
>
> Partially. It would solve the problem of losing track of the keepalive
> connections, but then you can't use keepalive, so the there's
> significant drawback with no real benefit.
>
> > There is a real reason for having new/different types of transports each
> time this specific func is called as they will (potentially) have different
> configs (mainly the SSL verify flag).
> >
> > Another option would be to create 2 global (?) clients one with- and one
> without SSL verify enabled, but that also doesn’t feel really clean…
>
> This is perfectly fine. You presumable have a finite number of
> configurations, so it's not hard to keep a reference to each one.
> While the http.Client itself isn't as big an issue, you will want to
> pair each transport with its own Client so that you aren't changing
> the Transport field while other calls are being made.
>
>
--
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.
For more options, visit https://groups.google.com/d/optout.
