hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Arun C Murthy (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HADOOP-538) Implement a nio's 'direct buffer' based wrapper over zlib to improve performance of java.util.zip.{De|In}flater as a 'custom codec'
Date Wed, 08 Nov 2006 04:04:53 GMT
    [ http://issues.apache.org/jira/browse/HADOOP-538?page=comments#action_12448019 ] 
            
Arun C Murthy commented on HADOOP-538:
--------------------------------------

1. Naming of .so's

The naming was done as exists so as to ensure we can easily 'know' whether libhadoop.so is
loaded or libhadoop-{platform-specific}.so and print out diagnostic information from NativeCodeLoader...

However if people feel strongly about it, here is a slight variation:

lib/native/prebuilt/Linux-i386-32/libhadoop.so  //pre-built, checked-in
build/hadoop-*/lib/native/prebuilt/Linux-i386-32/libhadoop.so // prebuilt packaged location


build/hadoop-*/lib/native/custom/Linux-i386-32/libhadoop.so // custom-built packaged location

2. package-native

Unfortunately we cannot just 'copy' libraries because of the need to invoke 'libtool' from
the package-native target, this is because only libtool understands the platform-specific
conventions about 'libraries' i.e. .so v/s .dll and so on... and hence a simple copy would
not suffice. Also we cannot invoke libtool from 'package' since we can't assume that 'libtool'
exists without 'compile-native'.... thus the need for a separate 'package-native' target.

3. CompressionCodec and 'Configurable'

I'll get this done, with a small caveat: We cannot get DefaultCodec to 'extend' Configured
since it would mean that we will need to add a new constructor to DefaultCodec (there is an
implicit constructor today) to satisfy the 'Configured' class, thus breaking the existing
public api. I can get around this by 
public class DefaultCodec implements Configurable, CompressionCodec {
  //...
}
Does that fly?




> 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.9.0
>
>         Attachments: HADOOP-538.patch, HADOOP-538_20061005.tgz, HADOOP-538_20061011.tgz,
HADOOP-538_20061026.tgz, HADOOP-538_20061030.tgz, HADOOP-538_20061107.tgz, 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

        

Mime
View raw message