[ https://issues.apache.org/jira/browse/THRIFT-5883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jean-Charles Quillet updated THRIFT-5883: ----------------------------------------- Description: I have a cpp server running transport "header" and protocol "binary" When a client sends a request using transport "buffered", protocol "binary". Everything works fine for the server and the client and no error is raised. When a client sends a request using transport "header", protocol "binary". Everything works fine from the client point of view. But on the server, I can see these errors, depending on the client. with a cpp client: {code:java} Thrift: Thu Jun 19 11:17:20 2025 TSocket::write_partial() send() <Host: 127.0.0.1 Port: 36622>: Broken pipe Thrift: Thu Jun 19 11:17:20 2025 TConnectedClient input close failed: write() send(): Broken pipe Thrift: Thu Jun 19 11:17:20 2025 TSocket::write_partial() send() <Host: 127.0.0.1 Port: 36622>: Broken pipe Thrift: Thu Jun 19 11:17:20 2025 TConnectedClient output close failed: write() send(): Broken pipe {code} with a python client: {code:java} Thrift: Thu Jun 19 11:21:00 2025 TConnectedClient output close failed: Called write on non-open socket {code} >From the experiment I did, it looks harmless (no fd nor memory leak). But >still there is definitly something that needs to be fixed here. See also THRIFT-5882 was: I have a cpp server running transport "header" and protocol "binary" When a client sends a request using transport "buffered", protocol "binary". Everything works fine for the server and the client and no error is raised. When a client sends a request using transport "header", protocol "binary". Everything works fine from the client point of view. But on the server, I can see these errors, depending on the client. with a cpp client: {code:java} Thrift: Thu Jun 19 11:17:20 2025 TSocket::write_partial() send() <Host: 127.0.0.1 Port: 36622>: Broken pipe Thrift: Thu Jun 19 11:17:20 2025 TConnectedClient input close failed: write() send(): Broken pipe Thrift: Thu Jun 19 11:17:20 2025 TSocket::write_partial() send() <Host: 127.0.0.1 Port: 36622>: Broken pipe Thrift: Thu Jun 19 11:17:20 2025 TConnectedClient output close failed: write() send(): Broken pipe {code} with a python client: {code:java} Thrift: Thu Jun 19 11:21:00 2025 TConnectedClient output close failed: Called write on non-open socket {code} >From the experiment I did, it looks armless (no fd nor memory leak). But still >there is definitly something that needs to be fixed here. See also THRIFT-5882 > [c++] Using "header" transport on both the client and server raises errors on > the server > ---------------------------------------------------------------------------------------- > > Key: THRIFT-5883 > URL: https://issues.apache.org/jira/browse/THRIFT-5883 > Project: Thrift > Issue Type: Bug > Components: C++ - Library > Affects Versions: 0.18.1, 0.22.0 > Reporter: Jean-Charles Quillet > Priority: Major > > I have a cpp server running transport "header" and protocol "binary" > When a client sends a request using transport "buffered", protocol "binary". > Everything works fine for the server and the client and no error is raised. > When a client sends a request using transport "header", protocol "binary". > Everything works fine from the client point of view. But on the server, I can > see these errors, depending on the client. > with a cpp client: > {code:java} > Thrift: Thu Jun 19 11:17:20 2025 TSocket::write_partial() send() <Host: > 127.0.0.1 Port: 36622>: Broken pipe > Thrift: Thu Jun 19 11:17:20 2025 TConnectedClient input close failed: write() > send(): Broken pipe > Thrift: Thu Jun 19 11:17:20 2025 TSocket::write_partial() send() <Host: > 127.0.0.1 Port: 36622>: Broken pipe > Thrift: Thu Jun 19 11:17:20 2025 TConnectedClient output close failed: > write() send(): Broken pipe > {code} > with a python client: > {code:java} > Thrift: Thu Jun 19 11:21:00 2025 TConnectedClient output close failed: Called > write on non-open socket > {code} > From the experiment I did, it looks harmless (no fd nor memory leak). But > still there is definitly something that needs to be fixed here. > See also THRIFT-5882 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)