[
https://issues.apache.org/jira/browse/THRIFT-5509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuxuan Wang resolved THRIFT-5509.
---------------------------------
Resolution: Fixed
> 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.14.0, 0.15.0, 0.14.1, 0.14.2
> Reporter: Yuxuan Wang
> Assignee: Yuxuan Wang
> Priority: Major
> Fix For: 0.16.0
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> Historically, for a TTransport, IsOpen returns false 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)
