[jira] [Updated] (THRIFT-3888) C++ socket linger values are different from Java

["William Slacum (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/THRIFT-3888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

William Slacum updated THRIFT-3888:
-----------------------------------
    Attachment: linger_off.patch

> 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
>         Attachments: linger_off.patch
>
>
> 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)