Mailing-List: contact mapreduce-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: mapreduce-issues@hadoop.apache.org
Date: Wed, 12 Sep 2012 13:29:08 +1100 (NCT)
From: "Suresh Srinivas (JIRA)" <jira@apache.org>
To: mapreduce-issues@hadoop.apache.org
Message-ID: <460594118.67233.1347416948689.JavaMail.jiratomcat@arcas>
In-Reply-To: 
 <1881365339.42733.1331282575710.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Updated] (MAPREDUCE-3992) Reduce fetcher doesn't verify
 HTTP status code of response
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Suresh Srinivas updated MAPREDUCE-3992:
---------------------------------------

    Fix Version/s: 1.1.0
    
> Reduce fetcher doesn't verify HTTP status code of response
> ----------------------------------------------------------
>
>                 Key: MAPREDUCE-3992
>                 URL: https://issues.apache.org/jira/browse/MAPREDUCE-3992
>             Project: Hadoop Map/Reduce
>          Issue Type: Bug
>          Components: mrv1
>    Affects Versions: 0.23.1, 0.24.0, 1.0.1
>            Reporter: Todd Lipcon
>            Assignee: Todd Lipcon
>             Fix For: 1.1.0, 0.23.3, 2.0.2-alpha
>
>         Attachments: mr-3992-branch-1.txt, mr-3992.txt
>
>
> Currently, the reduce fetch code doesn't check the HTTP status code of the response. This can lead to the following situation:
> - the map output servlet gets an IOException after setting the headers but before the first call to flush()
> - this causes it to send a response with a non-OK result code, including the exception text as the response body (response.sendError() does this if the response isn't committed)
> - it will still include the response headers indicating it's a valid response
> In the case of a merge-to-memory, the compression codec might then try to interpret the HTML response as compressed data, resulting in either a huge allocation (OOME) or some other nasty error. This bug seems to be present in MR1, but haven't checked trunk/MR2 yet.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira