[jira] [Comment Edited] (CALCITE-4676) Avatica client leaks TCP connections

["Istvan Toth (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CALCITE-4676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17375680#comment-17375680 ] 

Istvan Toth edited comment on CALCITE-4676 at 7/6/21, 12:37 PM:
----------------------------------------------------------------

The attached patch implements the 2nd option.

As a Pool must have identical SSL settings, we're creating a separate pool for every combination of SSL parameters set.
The SSL parameter handling is factored out from the client, and into CommonsHttpClientPoolCache, which maintains a Map of ssl parameters to pools.
When creating a new client, a pool is requested from CommonsHttpClientPoolCache, which will return an existing pool if it can.
I've kept the existing KeystorConfigurable, TrustStoreConfigurable and HostnameVerificationConfigurable interfaces for backwards compatibility reasons, but they are not used in the included implementation.
I've also merged the SPNEGO client into the main one. and introduced the GSSAuthenticable interface.




was (Author: stoty):
The attached patch implements the 2nd option.

As a Pool must have identical SSL settings, we're creating a separate pool for every combination of SSL parameters set.
The SSL parameter handling is factored out from the client, and into CommonsHttpClientPoolCache, which maintains a Map of ssl parameters to pools.
When creating a new client, a pool is requested from CommonsHttpClientPoolCache, which will return an existing pool if it can.
I've kept the existing KeystorConfigurable, TrustStoreConfigurable and HostnameVerificationConfigurable interfaces for backwards compatibility reasons, but they are not used in the included implementation.
I've also merged the SPNEGO client into the main one. and introduced the GSSAuthenticatable interface.



> Avatica client leaks TCP connections
> ------------------------------------
>
>                 Key: CALCITE-4676
>                 URL: https://issues.apache.org/jira/browse/CALCITE-4676
>             Project: Calcite
>          Issue Type: Bug
>          Components: avatica
>    Affects Versions: avatica-1.18.0
>            Reporter: Istvan Toth
>            Assignee: Istvan Toth
>            Priority: Major
>
> The default Http client implmentation uses org.apache.http.impl.conn.PoolingHttpClientConnectionManager to pool connections, and does not close the TCP connections explicitly when the JDBC connection is closed.
> However, the http client pools are created *per JDBC Connection*, so the pooling is effectively only used when concurrent statements are executed from the same Connection object.
> This also means that when the application opens and closes a lot of Connections, then every Connection leaves behind active (typically in CLOSE_WAIT) TCP connections, which are only cleaned up on GC.
> This wastes resources, and eventually breaks the application, as connection limits are reached.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)