Yuxuan Wang created THRIFT-5509:
-----------------------------------
Summary: 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
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)