hadoop-mapreduce-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hudson (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (MAPREDUCE-2258) IFile reader closes stream and compressor in wrong order
Date Thu, 19 May 2011 15:46:47 GMT

    [ https://issues.apache.org/jira/browse/MAPREDUCE-2258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13036258#comment-13036258

Hudson commented on MAPREDUCE-2258:

Integrated in Hadoop-Mapreduce-trunk #684 (See [https://builds.apache.org/hudson/job/Hadoop-Mapreduce-trunk/684/])
    MAPREDUCE-2258. IFile reader closes stream and compressor in wrong order. Contributed
by Todd Lipcon.

tomwhite : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1124383
Files : 
* /hadoop/mapreduce/trunk/CHANGES.txt
* /hadoop/mapreduce/trunk/src/java/org/apache/hadoop/mapred/IFile.java

> IFile reader closes stream and compressor in wrong order
> --------------------------------------------------------
>                 Key: MAPREDUCE-2258
>                 URL: https://issues.apache.org/jira/browse/MAPREDUCE-2258
>             Project: Hadoop Map/Reduce
>          Issue Type: Bug
>          Components: task
>    Affects Versions: 0.20.4, 0.22.0
>            Reporter: Todd Lipcon
>            Assignee: Todd Lipcon
>             Fix For: 0.23.0
>         Attachments: mapreduce-2258.txt
> In IFile.Reader.close(), we return the decompressor to the pool and then call close()
on the input stream. This is backwards and causes a rare race in the case of LzopCodec, since
LzopInputStream makes a few calls on the decompressor object inside close(). If another thread
pulls the decompressor out of the pool and starts to use it in the meantime, the first thread's
close() will cause the second thread to potentially miss pieces of data.

This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message