You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "Yuxuan Wang (Jira)" <ji...@apache.org> on 2022/02/03 18:21:00 UTC

[jira] [Created] (THRIFT-5509) Potential connection leaks caused by the connectivity check

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)