Skip to content

HDDS-16400. Fix thread-safety of positioned reads in OzoneFSInputStream - #11245

Open
taklwu wants to merge 4 commits into
apache:masterfrom
taklwu:HDDS-16400
Open

taklwu wants to merge 4 commits into
apache:masterfrom
taklwu:HDDS-16400

Conversation

@taklwu

@taklwu taklwu commented Sep 15, 2026

Copy link
Copy Markdown
Contributor

What changes were proposed in this pull request?

followup by HDDS-15424, we have created HDDS-16400 that implements the thread-safe positional read for OzoneFSInputStream

Please describe your PR in detail:

  1. ECBlockInputStream#readFully return false (use the default ExtendedInputStream#readFully), so it fail back to use the new additional synchronized lock for readSeekRestore.
  2. for those non-ByteBuffer / non-ByteBufferReadable inputstream, we have to use byte[] for seekReadRestore instead of casting with ByteBufferReadable

What is the link to the Apache JIRA

How was this patch tested?

unit tests.

Copilot AI lite review requested due to automatic review settings September 15, 2026 20:22

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 Changes recommended

One or more issues must be addressed before approval.

Get a fresh assessment by requesting another Copilot review.

Pull request overview

Improves thread safety for positional reads through Ozone filesystem and encrypted streams.

Changes:

  • Synchronizes fallback seek/read/restore operations.
  • Adds synchronized positional APIs to OzoneCryptoInputStream.
  • Adds concurrent positioned-read tests and the required test dependency.
File summaries
File Description
hadoop-ozone/ozonefs-common/src/test/java/org/apache/hadoop/fs/ozone/TestOzoneFSInputStream.java Updated as part of this pull request.
hadoop-ozone/ozonefs-common/src/main/java/org/apache/hadoop/fs/ozone/OzoneFSInputStream.java Updated as part of this pull request.
hadoop-ozone/ozonefs-common/pom.xml Updated as part of this pull request.
hadoop-ozone/client/src/main/java/org/apache/hadoop/ozone/client/io/OzoneCryptoInputStream.java Updated as part of this pull request.
Review details

Suppressed comments (2)

hadoop-ozone/client/src/main/java/org/apache/hadoop/ozone/client/io/OzoneCryptoInputStream.java:84

  • The synchronization added here does not cover inherited cursor-mutating operations such as skip. A concurrent skip can change CryptoInputStream's cursor or internal buffer while read(long, ByteBuffer) is between its seek/read/restore steps, so the positioned read can return corrupted data despite the new thread-safety guarantee. Override the cursor-mutating methods that are not already synchronized (at least skip), or narrow this documentation and the guarantee to the synchronized operations.
   * {@link CryptoInputStream} does not synchronize its own methods, so every method moving the cursor of
   * this stream is serialized here on the monitor of this stream. Otherwise a read or a seek could land in
   * the middle of a positioned read and see (or undo) the cursor move that read does.

hadoop-ozone/ozonefs-common/src/main/java/org/apache/hadoop/fs/ozone/OzoneFSInputStream.java:42

  • MultipartInputStream.readFully is not always stateless: its StreamBlockInputStream path performs a synchronized seek/read/restore sequence (see MultipartInputStream.java:197-233), while only the block path is stateless. Describing every successful ExtendedInputStream path as stateless is misleading for the concurrency guarantee; please call this the underlying positioned-read implementation or distinguish the two modes.
 * Sequential reads are not thread safe. Positioned reads use a native
 * stateless path when the underlying {@link ExtendedInputStream} supports it;
 * otherwise they fall back to a synchronized seek-read-restore sequence.
  • Files reviewed: 4/4 changed files
  • Comments generated: 2
  • Review effort level: Lite

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

@taklwu taklwu changed the title HDDS-16400. Make positional read thread-safe for OzoneCryptoInputStre… HDDS-16400. Support concurrent positioned reads in OzoneFSInputStream and OzoneCryptoInputStream Sep 15, 2026
@taklwu
taklwu requested a lite review from Copilot September 15, 2026 20:58

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔵 Needs a closer look

Validate read-only ByteBuffer destinations before positioned reads to prevent state corruption after an exception.

Review details

Suppressed comments (1)

hadoop-ozone/client/src/main/java/org/apache/hadoop/ozone/client/io/OzoneCryptoInputStream.java:183

  • A read-only destination is not rejected before the seek/read sequence. For an unaligned or short request, read(byte[], ...) sets readPositionAdjustedBy/readLengthAdjustedBy and then dst.put(...) throws ReadOnlyBufferException; the finally restores only the cursor, leaving those adjustment fields set, so the next valid read fails the precondition at getNumBytesToRead. Check dst.isReadOnly() before starting the positioned read (as the other ByteBuffer read path does).
  public synchronized int read(long position, ByteBuffer dst) throws IOException {
    if (!dst.hasRemaining()) {
      return 0;
  • Files reviewed: 5/5 changed files
  • Comments generated: 0 new
  • Review effort level: Lite

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 Changes recommended

Unresolved cursor-safety and byte-array positioned-read compatibility issues remain.

Get a fresh assessment by requesting another Copilot review.

Review details
  • Files reviewed: 5/5 changed files
  • Comments generated: 2
  • Review effort level: Lite

@taklwu taklwu changed the title HDDS-16400. Support concurrent positioned reads in OzoneFSInputStream and OzoneCryptoInputStream HDDS-16400. Fix thread-safety of positioned reads in OzoneFSInputStream Sep 15, 2026
@taklwu
taklwu requested a balanced review from Copilot September 15, 2026 22:42

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 Changes recommended

The byte-array overrides regress validation, EOF handling, and read statistics.

Get a fresh assessment by requesting another Copilot review.

Review details

Suppressed comments (1)

hadoop-ozone/ozonefs-common/src/main/java/org/apache/hadoop/fs/ozone/OzoneFSInputStream.java:258

  • This reimplementation loses two guarantees of the inherited readFully: it skips argument validation on the non-ExtendedInputStream path, and it treats ExtendedInputStream.readFully(...) == true as proof that the buffer is full. MultipartInputStream can return true after only reading the suffix available before EOF, so this silently leaves the array tail untouched instead of throwing. Now that the overridden read(...) uses the shared lock, delegate to the inherited validating loop.
  public void readFully(long position, byte[] buffer, int offset, int length) throws IOException {
    if (inputStream instanceof ExtendedInputStream) {
      final ByteBuffer buf = ByteBuffer.wrap(buffer, offset, length);
      try {
        if (((ExtendedInputStream) inputStream).readFully(position, buf)) {
  • Files reviewed: 3/3 changed files
  • Comments generated: 3
  • Review effort level: Balanced

@taklwu

taklwu commented Sep 16, 2026

Copy link
Copy Markdown
Contributor Author

@szetszwo This is the first split PR for OzoneFSInputStream, focusing mainly on input streams that do not implement ExtendedInputStream (aka EC). meanwhile we will have OzoneCryptoInputStream support thread-safe positional read in next PR.

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.

3 participants