[
https://issues.apache.org/jira/browse/HADOOP-10047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13804209#comment-13804209
]
Gopal V commented on HADOOP-10047:
----------------------------------
[~cmccabe]: oh, hell no! It was just a way to test-drive the API (as you said,
you wanted to see the API used before it was baked in).
With that example, I think I have finally figure out a way to not write more
native code (I'd use the phrase "attack surface", considering my security work).
All it needs is for a relatively safe protected exposure of inflateDirect()
(and friends), which does the appropriate buffer swaps there.
That franken-zlib there clearly illustrates how I only need new interfaces to
expose existing code for record compression case (i.e no loop around
decompress(), in particular for SNAPPY).
> Allow Compressor/Decompressor APIs to expose a Direct ByteBuffer API
> --------------------------------------------------------------------
>
> Key: HADOOP-10047
> URL: https://issues.apache.org/jira/browse/HADOOP-10047
> Project: Hadoop Common
> Issue Type: New Feature
> Components: io
> Reporter: Gopal V
> Assignee: Gopal V
> Labels: compression
> Attachments: DirectCompressor.html, DirectDecompressor.html,
> HADOOP-10047-WIP.patch, HADOOP-10047-with-tests.patch
>
>
> With the Zero-Copy reads in HDFS (HDFS-5260), it becomes important to perform
> all I/O operations without copying data into byte[] buffers or other buffers
> which wrap over them.
> This is a proposal for adding new DirectCompressor and DirectDecompressor
> interfaces to the io.compress, to indicate codecs which want to surface the
> direct buffer layer upwards.
> The implementation may or may not copy the buffers passed in, but should work
> with direct heap/mmap buffers and cannot assume .array() availability.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
