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