http.Transport: separating the connection pooling aspect
434 views
Skip to first unread message
Sangjin Lee
Oct 31, 2017, 1:18:14 PM10/31/17
to golang-dev
I posted this inquiry on golang-nuts, but I hope it is appropriate for golang-dev as well.
We enjoy using http.Transport as it gives us a real solid HTTP client functionality and faithful protocol implementation. The connection pooling/management is also bundled into http.Transport. That's the part I'd like to discuss. The http.Transport connection management takes a stance on a few areas. For example,
- it does not limit the number of *active* connections
- it reuses available connections in a LIFO manner
There are real needs and use cases where we need a different behavior there. We may want to limit the number of active connections. We may want to have a different connection pooling policy (e.g. FIFO). But today it is not possible if you use http.Transport. The only option is to implement the HTTP client, but we like the protocol implementation that exists in http.Transport.
This is probably more of a go 2 suggestion, but it would be great if these policies are configurable first of all so that we can realize different policies than the current hard-coded ones. Even better, it would be awesome if the connection management aspect of http.Transport is separated from the protocol aspect of http.Transport and become pluggable (e.g. a ConnectionManager interface). Then we could choose to provide a different connection management implementation and mix it with the protocol support of http.Transport.
It would be great if it could be considered a go 2 candidate. I suspect it would help a lot of folks that are using http.Transport (or Client) today that do not want to reinvent the wheel on the protocol implementation. Thoughts?
Regards,
Sangjin
We enjoy using http.Transport as it gives us a real solid HTTP client functionality and faithful protocol implementation. The connection pooling/management is also bundled into http.Transport. That's the part I'd like to discuss. The http.Transport connection management takes a stance on a few areas. For example,
- it does not limit the number of *active* connections
- it reuses available connections in a LIFO manner
There are real needs and use cases where we need a different behavior there. We may want to limit the number of active connections. We may want to have a different connection pooling policy (e.g. FIFO). But today it is not possible if you use http.Transport. The only option is to implement the HTTP client, but we like the protocol implementation that exists in http.Transport.
This is probably more of a go 2 suggestion, but it would be great if these policies are configurable first of all so that we can realize different policies than the current hard-coded ones. Even better, it would be awesome if the connection management aspect of http.Transport is separated from the protocol aspect of http.Transport and become pluggable (e.g. a ConnectionManager interface). Then we could choose to provide a different connection management implementation and mix it with the protocol support of http.Transport.
It would be great if it could be considered a go 2 candidate. I suspect it would help a lot of folks that are using http.Transport (or Client) today that do not want to reinvent the wheel on the protocol implementation. Thoughts?
Regards,
Sangjin
Brad Fitzpatrick
Oct 31, 2017, 1:22:49 PM10/31/17
to Sangjin Lee, Tom Bergan, golang-dev
I agree.
I suspect Tom (copied) does too.
I suspect it's something we'd be able to add to *http.Transport with a new optional field of some interface type even in Go 1.x. That could resolve a number of open feature request bugs in this area. It'd need some careful design around how HTTP/1 -> HTTP/2 upgrade works, though, which complicates the current code.
--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Sangjin Lee
Oct 31, 2017, 5:31:04 PM10/31/17
to Brad Fitzpatrick, Tom Bergan, golang-dev
That is fantastic! Thanks Brad. It would be awesome if we can accomplish this in go 1.x.
From the user perspective, coming up with a solid API for a "connection manager" would be quite important. It would be even better if implementers can reuse most of the "default" connection manager implementations and override only the parts that they need different behavior for.
I'm not 100% familiar with the process, but I'd love to be part of the discussion to shape the requirements and possibly the work that it requires to get there. How do we move forward?
Sangjin
Brad Fitzpatrick
Nov 1, 2017, 2:45:33 PM11/1/17
to Sangjin Lee, Tom Bergan, golang-dev
Start by filing a bug about coming up with a design. (or include an initial design if you have one)
You can use the https://github.com/golang/proposal#readme template if you'd like.
When filing a bug, try to find the related handful of open bugs and show how the design would address the existing bugs.
Tom Bergan
Nov 1, 2017, 3:51:17 PM11/1/17
to Brad Fitzpatrick, Sangjin Lee, golang-dev
I agree with Brad. Such an interface would resolve many feature requests, including features we've added in the past and feature requests that are pending. Related issues that I could find after a quick search:
As Brad alluded to, I think the main challenge is deciding to what extent this will work with HTTP/2. The second challenge is handling proxies. Not only do we need to consider all types of proxies we support currently (see connectMethod in net/http/transport.go), but we also need to define the interface broadly enough that it is possible to support other kinds of proxies later (as one example, see the recently-added support for https proxies).
Steven Hartland
Nov 1, 2017, 5:11:17 PM11/1/17
to Brad Fitzpatrick, Tom Bergan, Sangjin Lee, golang-dev
Another relavent issue is how http2 now blocks if MaxConcurrentStreamsing is hit. While this may sounds like a good idea it actually prevents http2 from being used easily for workloads which require multiple connections e.g. where BDP is the limiting factor.
The following is the commit which changed this behaviour causing the problem.
Hence having control of how new connections are managed under http2 would be worth considering in this.
Sangjin
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
Sangjin Lee
Nov 1, 2017, 8:09:28 PM11/1/17
to Steven Hartland, Brad Fitzpatrick, Tom Bergan, golang-dev
Sangjin
Sangjin
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages