[
https://issues.apache.org/jira/browse/HADOOP-3646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617618#action_12617618
]
Chris Douglas commented on HADOOP-3646:
---------------------------------------
This is looking very good, particularly as a first pass. There are only a few
minor tweaks remaining:
* The latest patch includes an artifact from the original, which employed a
try-catch block:
{noformat}
public CompressionInputStream createInputStream(InputStream in)
throws IOException {
CompressionInputStream compressionInputStream = null;
compressionInputStream = new BZip2CompressionInputStream(in);
return compressionInputStream;
}
{noformat}
* createInputStream(InputStream, Decompressor) throws
UnsupportedOperationException while createOutputStream(OutputStream,
Compressor) ignores the second argument. These should be symmetric,
particularly since one cannot create a valid Compressor or Decompressor. The
latter should also throw.
* The {{ERROR_MESSAGE}} ("Feature currently not supported") message around an
UnsupportedOperationException doesn't add any information and may be omitted;
similarly, not only is the error message from the BZip2CompressionInputStream
and BZip2CompressionOutputStream unconventionally descriptive, the purpose of
adding constructors that only throw UnsupportedOperationException from a
private, static inner class is not clear to me. Is either necessary? Wouldn't
it make more sense to add these when the associated Compressor and
Decompressors are included?
> Providing bzip2 as codec
> ------------------------
>
> Key: HADOOP-3646
> URL: https://issues.apache.org/jira/browse/HADOOP-3646
> Project: Hadoop Core
> Issue Type: Improvement
> Components: conf, io
> Affects Versions: 0.19.0
> Reporter: Abdul Qadeer
> Assignee: Abdul Qadeer
> Fix For: 0.19.0
>
> Attachments: HADOOP-3646-version4.patch, HADOOP-3646.patch,
> HADOOP-3646.patch, HADOOP-3646version3.patch
>
> Original Estimate: 1008h
> Remaining Estimate: 1008h
>
> Hadoop recognizes gzip compressed input and automatically decompresses the
> data before providing it to the mapper. But Hadoop can not split a gzip
> stream due to the very nature of the gzip compression. Consequently one gzip
> stream (e.g a whole file) can go to only one mapper. On the contrary Bzip2
> compressed stream can be split across its block delimiters.
> We are interested in extending Hadoop to support splittable bzip2 with a
> codec. (https://issues.apache.org/jira/browse/HADOOP-1823 uses input reader
> to split the bzip2 files, which must be provided by the user and can handle
> FileInputFormat. If a user wants to use some other input format or wants to
> do custom record handling, he must write a new input reader!)
> We have a patch now that provides a basic bzip2 codec equivalent to the
> current gzip codec. We are in the process of extending that to support
> splitting.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
