Mailing-List: contact mapreduce-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: mapreduce-issues@hadoop.apache.org
Date: Mon, 10 Jun 2013 21:50:22 +0000 (UTC)
From: "Jason Lowe (JIRA)" <jira@apache.org>
To: mapreduce-issues@hadoop.apache.org
Message-ID: <JIRA.12651495.1370555215767.96187.1370901022020@arcas>
In-Reply-To: <JIRA.12651495.1370555215767@arcas>
References: <JIRA.12651495.1370555215767@arcas>
Subject: [jira] [Updated] (MAPREDUCE-5308) Shuffling to memory can get
 out-of-sync when fetching multiple compressed map outputs
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Jason Lowe updated MAPREDUCE-5308:
----------------------------------

       Resolution: Fixed
    Fix Version/s: 0.23.9
                   2.1.0-beta
     Hadoop Flags: Reviewed
           Status: Resolved  (was: Patch Available)

Thanks, Nathan!  I committed this to trunk, branch-2, branch-2.1-beta and branch-0.23.
                
> Shuffling to memory can get out-of-sync when fetching multiple compressed map outputs
> -------------------------------------------------------------------------------------
>
>                 Key: MAPREDUCE-5308
>                 URL: https://issues.apache.org/jira/browse/MAPREDUCE-5308
>             Project: Hadoop Map/Reduce
>          Issue Type: Bug
>    Affects Versions: trunk, 2.0.3-alpha, 0.23.8
>            Reporter: Nathan Roberts
>            Assignee: Nathan Roberts
>             Fix For: 2.1.0-beta, 0.23.9
>
>         Attachments: MAPREDUCE-5308-branch-0.23.txt, MAPREDUCE-5308.patch
>
>
> When a reducer is fetching multiple compressed map outputs from a host, the fetcher can get out-of-sync with the IFileInputStream, causing several of the maps to fail to fetch.
> This occurs because decompressors can return all the decompressed bytes before actually processing all the bytes in the compressed stream (due to checksums or other trailing data that we ignore). In the unfortunate case where these extra bytes cross an io.file.buffer.size boundary, some extra bytes will be left over and the next map_output will not fetch correctly (usually due to an invalid map_id).
> This scenario is not typically fatal to a job because the failure is charged to the map_output immediately following the "bad" one and the subsequent retry will normally work. 

--
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