[
https://issues.apache.org/jira/browse/HADOOP-13047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15256495#comment-15256495
]
Steve Loughran commented on HADOOP-13047:
-----------------------------------------
# I like the simplicity of this being a buffer.
# There's no need to actually have a separate read+discard loop to go past the
available bytes; .skip() will do that, simply blocking until the data is ready.
(Though a sanity check at the end is probably wise)
# I'd like that buffer size to be settable via setReadahead(). Why? It would
allow applications which *really* knew what they were doing to actually set
readahead for their algorithms. Though I don't see any evidence of that method
being used anywhere in the Hadoop codebase —does anyone have any data on how
often code uses it?
# Patch -002 of HADOOP-13028 exposes the statistics of a stream via a visible
for testing method...this would all you to write a test which verified that a
forward seek within the buffer range worked. This is where that
{{setReadahead()}} call would really be useful, as you could change the buffer
size and verify that forward seeks simply increment the counter of bytes
skipped on seek; the number of stream close/open events would be unchanged.
> S3a Forward seek in stream length to be configurable
> ----------------------------------------------------
>
> Key: HADOOP-13047
> URL: https://issues.apache.org/jira/browse/HADOOP-13047
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: fs/s3
> Affects Versions: 2.8.0
> Reporter: Steve Loughran
> Attachments: HADOOP-13047.WIP.2.patch, HADOOP-13047.WIP.patch
>
>
> Even with lazy seek, tests can show that sometimes a short-distance forward
> seek is triggering a close + reopen, because the threshold for the seek is
> simply available bytes in the inner stream.
> A configurable threshold would allow data to be read and discarded before
> that seek. This should be beneficial over long-haul networks as the time to
> set up the TCP channel is high, and TCP-slow-start means that the ramp up of
> bandwidth is slow. In such deployments, it will better to read forward than
> re-open, though the exact "best" number will vary with client and endpoint.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
