[ 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)