[
https://issues.apache.org/jira/browse/CALCITE-4676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17374719#comment-17374719
]
Istvan Toth commented on CALCITE-4676:
--------------------------------------
I can see two ways to solve this:
1. Keep most of the current implementation, but shut down the pool when the
JDBC connection is closed.
This promises to be relatively straightforward, but as the internal API does
not support closing the underlying http connections or pools, requires a
sizable internal refactor. It also does not pool the TCP connection optimally.
2. Switch to using a global PoolingHttpClientConnectionManager.
For most intents, PoolingHttpClientConnectionManager is intelligent enough to
work correctly for different hosts/ports, and even principals are handled
correctly.
Looking at the code, only the SSL parameters need to be set at pool level, so
it looks like we only need to create different pools for different SSL
settings, which for most use cases means creating and using a single connection
pool.
> 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)
