Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GH-3080: HadoopStreams to support ByteBufferPositionedReadable #3096

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

steveloughran
Copy link
Contributor

Rationale for this change

If a stream declares in its StreamCapabilities that it supports
ByteBufferPositionedReadable, then use that API for
readFully(ByteBuffer)

ByteBufferPositionedReadable.readFully(long position, ByteBuffer buf)

Adding support for Hadoop ByteBufferPositionedReadable streams may improve performance
by pushing retry/recovery logic into the filesystem client library.

This interface is implemented by the HDFS input stream; we are considering adding
it elsewhere.

What changes are included in this PR?

  • New SeekableInputStream implementation: H3ByteBufferInputStream
  • Instantiated in HadoopStreams if the FSDataInputStream is considered suitable.
  • Tests for the new behavior and that no regressions are caused.

Class H3ByteBufferInputStream

The reading is done in a new class, H3ByteBufferInputStream, which subclasses H2ByteBufferInputStream. This reduces the amount of duplicate code, it just makes it a bit unclean.

The purist way to do it would be to create an abstract superclass HadoopInputStream to hold all commonality between the the three input streams.

I'm happy to do this, just didn't want to doing some larger refactoring without (a) showing the core design worked and (b) getting permission to do this. Should I do this?

HadoopStreams changes

Selection of the new input stream is done if and only if the stream declares the capability in:preadbytebuffer.
There is no equivalent of isWrappedStreamByteBufferReadable() which recurses through
a chain of wrapped streams looking for the API.
If a stream doesn't declare its support for the API, it won't get picked up.
This is done knowing that the sole production implemenation which currently exists,
the HDFS input stream, does declare this capability.

Are these changes tested?

There is new test suite, for new behavior and ensuring that the integration with
HadoopStreams still retains the correct behavior for existing streams.
Suite is parameterized on heap and direct buffers.

Are there any user-facing changes?

No

Closes GH-3080

Based of the H2 stream test suite but
* parameterized for on/off heap
* expect no changes in buffer contents on out of range reads.

Still one test failure.
* changing how stream capabilities are set up and queried,
  makes it easy to generate streams with different declared
  behaviours.
* pull out common assertions
* lots of javadoc of what each test case is trying to do.

+ all the tests are happy.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

HadoopStreams to support ByteBufferPositionedReadable input streams
1 participant