[jira] [Commented] (TEZ-3633) Implement keep-alive timeout in tez shuffle handler

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

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

TezQA commented on TEZ-3633:
----------------------------

{color:green}+1 overall{color}.  Here are the results of testing the latest attachment
  http://issues.apache.org/jira/secure/attachment/12870092/TEZ-3633.2.patch
  against master revision 542a199.

    {color:green}+1 @author{color}.  The patch does not contain any @author tags.

    {color:green}+1 tests included{color}.  The patch appears to include 1 new or modified test files.

    {color:green}+1 javac{color}.  The applied patch does not increase the total number of javac compiler warnings.

    {color:green}+1 javadoc{color}.  There were no new javadoc warning messages.

    {color:green}+1 findbugs{color}.  The patch does not introduce any new Findbugs (version 3.0.1) warnings.

    {color:green}+1 release audit{color}.  The applied patch does not increase the total number of release audit warnings.

    {color:green}+1 core tests{color}.  The patch passed unit tests in .

Test results: https://builds.apache.org/job/PreCommit-TEZ-Build/2478//testReport/
Console output: https://builds.apache.org/job/PreCommit-TEZ-Build/2478//console

This message is automatically generated.

> Implement keep-alive timeout in tez shuffle handler
> ---------------------------------------------------
>
>                 Key: TEZ-3633
>                 URL: https://issues.apache.org/jira/browse/TEZ-3633
>             Project: Apache Tez
>          Issue Type: Sub-task
>            Reporter: Jonathan Eagles
>            Assignee: Jonathan Eagles
>         Attachments: TEZ-3633.1.patch, TEZ-3633.2.patch, with_hadoop_2.7.3.png
>
>
> MAPREDUCE-5787 which added keep-alive to mapreduce shuffle handler was not fully functional as despite advertising keep-alive option and adding the  header to the response, all connections were closed immediately after write. This reduced the performance of certain fetches as now time is spent requesting a second get to the same serve, only for that server to reset the connection forcing the client to reestablish the connection on another port. The details of this is hidden behind HttpURLConnection and doesn't show in any log file at default logging level. However TCP sniffing does show errant behavior.



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