[
http://issues.apache.org/jira/browse/HADOOP-538?page=comments#action_12438478 ]
Owen O'Malley commented on HADOOP-538:
--------------------------------------
Ok, I think we need a class that is responsible for trying to load libhadoop.so
and having fall back replacements.
package org.apache.hadoop.util;
public class NativeCode {
private static boolean inFallback = true;
public static Class<DF> getDFClass() { ... }
public static Class<CompressionCodec> getDefaultCodecClass() { ... }
public static Class<CompressionCodec> getGzipCodecClass(){...}
static {
// try to load libhadoop.so and set fallback flag appropriately
}
}
Does that look reasonable?
I think that we'd be fine with libhadoop-${os.name}-${os.arch}.so for the most
part. Especially if we keep C++ out of the APIs. *smile* I don't think we
should try to determine the distro or get into that game.
> Implement a nio's 'direct buffer' based wrapper over zlib to improve
> performance of java.util.zip.{De|In}flater as a 'custom codec'
> -----------------------------------------------------------------------------------------------------------------------------------
>
> Key: HADOOP-538
> URL: http://issues.apache.org/jira/browse/HADOOP-538
> Project: Hadoop
> Issue Type: Improvement
> Affects Versions: 0.6.1
> Reporter: Arun C Murthy
> Assigned To: Arun C Murthy
> Fix For: 0.7.0
>
> Attachments: HADOOP-538.patch, HADOOP-538_benchmarks.tgz
>
>
> There has been more than one instance where java.util.zip's {De|In}flater
> classes perform unreliably, a simple wrapper over zlib-1.2.3 (latest stable)
> using java.nio.ByteBuffer (i.e. direct buffers) should go a long way in
> alleviating these woes.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
