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)