William Slacum created THRIFT-3888:
--------------------------------------
Summary: C++ socket linger values are different from Java
Key: THRIFT-3888
URL: https://issues.apache.org/jira/browse/THRIFT-3888
Project: Thrift
Issue Type: Bug
Components: C++ - Library, Java - Library
Affects Versions: 0.9.3
Environment: osx
Reporter: William Slacum
I have a service that I defined in Thrift, say:
{code}
service echo {
string echo(1: string s)
}
{code}
I create a server written in Java. I also create a Java client and a C++
client. If I execute the Java one, it can cleanly echo the string back with no
errors on the client or server (assuming good conditions across the network and
such). If I execute the C++ client, I can have my string echo'd back to me, but
the server reports an error:
{code:java}
[Thread-22] WARN org.apache.thrift.server.AbstractNonblockingServer$FrameBuffer
- Got an IOException in internalRead!
java.io.IOException: Connection reset by peer
at sun.nio.ch.FileDispatcherImpl.read0(Native Method)
at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
at sun.nio.ch.IOUtil.read(IOUtil.java:197)
at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:380)
at
org.apache.thrift.transport.TNonblockingSocket.read(TNonblockingSocket.java:142)
at
org.apache.thrift.server.AbstractNonblockingServer$FrameBuffer.internalRead(AbstractNonblockingServer.java:539)
at
org.apache.thrift.server.AbstractNonblockingServer$FrameBuffer.read(AbstractNonblockingServer.java:338)
at
org.apache.thrift.server.AbstractNonblockingServer$AbstractSelectThread.handleRead(AbstractNonblockingServer.java:203)
at
org.apache.thrift.server.TThreadedSelectorServer$SelectorThread.select(TThreadedSelectorServer.java:586)
at
org.apache.thrift.server.TThreadedSelectorServer$SelectorThread.run(TThreadedSelectorServer.java:541)
{code}
(I was using a `TThreadedSelectorServer` and `TCompactProtocol` on my server,
with a matching `TFramedTransport` and protocol on the client)
I delved into Wireshark and saw that the C++ client *always* sent the server an
RST, where as the Java client would go through the regular old {{FIN}} sequence
to cleanly close the connection.
This boils down to the C++ TSocket implementation turning on {{linger}}, but
setting the timeout to 0. Two workarounds are to disable {{linger}} by default,
or to set a positive timeout value. I think Thrift's protocol is robust enough
to handle no linger, but would like some opinions from the community.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
