Mailing-List: contact dev-help@thrift.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@thrift.apache.org
Date: Thu, 18 May 2017 12:49:04 +0000 (UTC)
From: "James E. King, III (JIRA)" <jira@apache.org>
To: dev@thrift.apache.org
Message-ID: <JIRA.13073032.1495091746000.240771.1495111744161@Atlassian.JIRA>
In-Reply-To: <JIRA.13073032.1495091746000@Atlassian.JIRA>
References: <JIRA.13073032.1495091746000@Atlassian.JIRA> <JIRA.13073032.1495091746161@jira-lw-us.apache.org>
Subject: [jira] [Commented] (THRIFT-4201) False positive timeout or wrongly
 blocking recv in the THttpTransport client
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Thu, 18 May 2017 12:49:10 -0000


    [ https://issues.apache.org/jira/browse/THRIFT-4201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16015699#comment-16015699 ] 

James E. King, III commented on THRIFT-4201:
--------------------------------------------

I failed to mention in my previous comment - thank you for the detailed bug report and resolution!

> False positive timeout or wrongly blocking recv in the THttpTransport client
> ----------------------------------------------------------------------------
>
>                 Key: THRIFT-4201
>                 URL: https://issues.apache.org/jira/browse/THRIFT-4201
>             Project: Thrift
>          Issue Type: Bug
>          Components: C++ - Library
>    Affects Versions: 0.10.0
>         Environment: Linux 64 bit - CentOS Linux release 7.3.1611 
>            Reporter: Iliya Gurov
>              Labels: C++, C++11, client, http, patch, transport
>         Attachments: httpTransportClientPatch.patch, uts2.pcap
>
>
> Before we get more data by doing refill in the *THttpTransport::readMoreData()*, we need to check whether we have already the entire content in the buffer (fetched in the last *::recv* in *TSocket::read()* while processing the previous chunk). Doing refill without this check may lead to calling *::recv* even though all chunks (the entire content) are already in the buffer. The effect of this is that the call fails either with a false positive timeout or blocks in recv if no timeout is configured.
> Attached is the suggested patch and tcpdump pcap (you can clearly see there that we wait for more data although we have already ACKed the last piece of byte - tcp.stream eq 26).


--
This message was sent by Atlassian JIRA
(v6.3.15#6346)