[
https://issues.apache.org/jira/browse/CALCITE-4676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17375783#comment-17375783
]
Josh Elser commented on CALCITE-4676:
-------------------------------------
Quite a find!
bq. 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.
Ok, that's a pretty obvious gap in how we got here. Of course, we don't expect
users to spin through making lots of Connections, but we should have also
expected they would do this :)
> 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)
