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

Istvan Toth commented on CALCITE-4676:
--------------------------------------

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)

Reply via email to