[
https://issues.apache.org/jira/browse/THRIFT-5509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17486650#comment-17486650
]
Duru Can Celasun commented on THRIFT-5509:
------------------------------------------
Option 2, definitely.
> Potential connection leaks caused by the connectivity check
> -----------------------------------------------------------
>
> Key: THRIFT-5509
> URL: https://issues.apache.org/jira/browse/THRIFT-5509
> Project: Thrift
> Issue Type: Improvement
> Components: Go - Library
> Affects Versions: 0.15.0
> Reporter: Yuxuan Wang
> Assignee: Yuxuan Wang
> Priority: Major
>
> Historically, for a TTransport, IsOpen returns true means that the connection
> is already explicitly closed. So third party code (for example, client pool
> management logic) could just throw the connection away after IsOpen returned
> false without worry.
> But since the adding of connectivity check in go library (first release
> version 0.14.0), that is no longer true: IsOpen could return true when the
> remote closed the connection, and in such cases Close shall still be
> explicitly called. If we just throw the connection away without explicitly
> calling Close, the action of "throw away the connection" will cause
> connection leaks.
> There are 2 ways to mitigate it:
> # Document in IsOpen that IsOpen returning false does not necessarily mean
> the connection is already closed, and an explicit Close call is still needed.
> # Implicitly call Close inside IsOpen when connectivity check fails. This
> way we keep the assumption that IsOpen returns false means Close was already
> called being true.
> [~dcelasun] what's your preference between the 2 paths?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
