[
https://issues.apache.org/jira/browse/HDFS-8957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15010357#comment-15010357
]
Kai Zheng commented on HDFS-8957:
---------------------------------
Hi Walter, thanks for your comments!
You mentioned a corner case where no big enough application's buffer can be
leveraged for decoding and new buffers like *curStripeBuf* will surely be
allocated to proceed with. Note anyway for a decoding call a time 9 cells will
be fetched and used, even less than a cell/strip is requested. The codes are
taken from a local branch we used to perform benchmark extensive testing and
work fine and the performance gain over this change for stateful read is
noticeable. I will double check the case and ensure it's well handled. Probably
new unit tests for such consideration will be added.
> Consolidate client striping input stream codes for stateful read and
> positional read
> ------------------------------------------------------------------------------------
>
> Key: HDFS-8957
> URL: https://issues.apache.org/jira/browse/HDFS-8957
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Reporter: Kai Zheng
> Assignee: Kai Zheng
> Fix For: HDFS-7285
>
> Attachments: HDFS-8957-v1.patch
>
>
> Currently we have different implementations for client striping read, having
> both *StatefulStripeReader* and *PositionStripeReader*. I attempted to
> consolidate the two implementations into one, and it results in much simpler
> codes, and also better performance. Now in both read paths, it will:
> * Use pooled ByteBuffers, as currently stateful read does;
> * Read directly into application's buffer, as currently positional read does;
> * Try to align and merge multiple stripes, as currently positional read does;
> * Use *ECChunk* version decode API.
> The resultant *StripeReader* is approaching very near now to the ideal state
> desired by next step, employing *ErasureCoder* API instead of
> *RawErasureCoder* API.
> Will upload an initial patch to illustrate the rough change, even though it
> depends on other issues.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
