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