[
https://issues.apache.org/jira/browse/THRIFT-3429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15012328#comment-15012328
]
Adam Beberg commented on THRIFT-3429:
-------------------------------------
The current behavior is correct in keeping the connection open to avoid having
to do the TLS handshaking and setup (which you _are_ using, right?) every time
destroying performance on both the client and server. If you want a one-shot
HTTP call because they are rare, you should call close() when you're done - you
should always close when you're "done". Servers can handle millions of long
lived TLS connections at a time these days so it's not a worry, the
setup/teardown overhead is far more damaging.
The HTTP transport should be kept as simple as possible.
> Go THttpClient option to fully read/close HTTP response body after Flush
> ------------------------------------------------------------------------
>
> Key: THRIFT-3429
> URL: https://issues.apache.org/jira/browse/THRIFT-3429
> Project: Thrift
> Issue Type: Improvement
> Components: Go - Library
> Reporter: Justin Larrabee
> Priority: Minor
>
> Currently the THttpTransport holds onto the HTTP response body until the
> owner calls Close(). When using keepalive this has the side effect of not
> releasing the TCP connection back to the HTTP client's pool until it is
> called. When creating many concurrent THttpTransport's this delay can cause a
> lot of additional connections to be created.
> I would suggest that the transport be configurable to fully read and close
> the HTTP response body after a Flush() call so that the connection is
> returned to the pool as quickly as possible.
> I would love some opinions on this suggestion. My patch for issue 3405 added
> a THttpClientOptions struct to make it easy to support additional features
> like this improvement without needing to alter the new public constructors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
