[
https://issues.apache.org/jira/browse/HBASE-7145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13536195#comment-13536195
]
stack commented on HBASE-7145:
------------------------------
You do this + JVM jvm = new JVM();. Is it needed? Can all in JVM be
static (I've not looked... makes it less useful if have to instantiate it to
use it). Then you do private static boolean HAS_BROKEN_FINISH =
JVM.isBrokenFinish();
Thanks.
> ReusableStreamGzipCodec NPE upon reset with IBM JDK
> ---------------------------------------------------
>
> Key: HBASE-7145
> URL: https://issues.apache.org/jira/browse/HBASE-7145
> Project: HBase
> Issue Type: Sub-task
> Affects Versions: 0.94.0
> Reporter: Yu Li
> Assignee: Yu Li
> Labels: gzip, ibm-jdk
> Fix For: 0.96.0
>
> Attachments: 7145-trunk-v3.txt, HBASE-7145.1.patch.txt,
> HBASE-7145.2_trunk.patch.txt
>
>
> This is the same issue as described in HADOOP-8419, repeat the issue
> description here:
> The ReusableStreamGzipCodec will NPE upon reset after finish when the native
> zlib codec is not loaded. When the native zlib is loaded the codec creates a
> CompressorOutputStream that doesn't have the problem, otherwise, the
> ReusableStreamGzipCodec uses GZIPOutputStream which is extended to provide
> the resetState method. Since IBM JDK 6 SR9 FP2 including the current JDK 6
> SR10, GZIPOutputStream#finish will release the underlying deflater(calls the
> deflater's end method), which causes NPE upon reset. This seems to be an IBM
> JDK quirk as Sun JDK and OpenJDK doesn't have this issue.
> Since in HBASE-5387 HBase source has refactor its code not to use hadoop's
> GzipCodec during real compress/decompress, it's necessary to make a separate
> patch for HBase on the same issue
--
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
