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

Todd Lipcon commented on MAPREDUCE-2258:
----------------------------------------

Hong: I agree LzoCodec is preferable to LzopCodec for use in intermediate 
compression, but I think the bug you referenced is no longer the case. 
LzopCodecs can now be pooled properly with Chris's patch you referenced plus 
changes on the lzo side.

Just to clarify, you agree this code in IFile is wrong and should be fixed, 
right?

> 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
>             Fix For: 0.22.0
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.

Reply via email to