Skip to content

HDDS-10283. [WIP] Apply zero copy to Ozone client reads#10369

Draft
smengcl wants to merge 7 commits into
apache:masterfrom
smengcl:HDDS-10283-client-read-chunk-zerocopy
Draft

HDDS-10283. [WIP] Apply zero copy to Ozone client reads#10369
smengcl wants to merge 7 commits into
apache:masterfrom
smengcl:HDDS-10283-client-read-chunk-zerocopy

Conversation

@smengcl
Copy link
Copy Markdown
Contributor

@smengcl smengcl commented May 27, 2026

Generated-by: Claude Code (Opus 4.7)
Generated-by: Codex (GPT-5.4)

Finishing what @duongkame left off.

What changes were proposed in this pull request?

  • Add an explicit zero-copy ReadChunk path for client reads.
  • Keep the existing readChunk() path unchanged for compatibility.
  • Release zero-copy responses correctly on retry/validation paths, and add coverage for both legacy and zero-copy callers.

Mirrors the existing server-side request-side zero-copy pattern in GrpcXceiverService.bindServiceWithZeroCopy.

What is the link to the Apache JIRA

https://issues.apache.org/jira/browse/HDDS-10283

How was this patch tested?

  • Parameterized test cases to test zero copy path.

Install a ZeroCopyMessageMarshaller (from ratis-thirdparty) as the
response marshaller for the XceiverClient.send bidi-stream RPC. The
marshaller wraps the inbound Netty buffer as proto3 ByteString via
UnsafeByteOperations.unsafeWrap, so the chunk-data field of a ReadChunk
response no longer requires a chunk-sized memcpy on the client.

Lifecycle:
- ReadChunk responses keep the Netty buffer alive: ContainerProtocolCalls
  returns the outer ContainerCommandResponseProto so that ChunkInputStream
  can hold the reference until releaseBuffers() runs, at which point it
  calls XceiverClientSpi.releaseReceivedResponse to return the buffer to
  the pool.
- All other response types are deep-copied inside the wrapping marshaller
  and the original buffer-aliased response is released immediately, so
  callers never observe an aliased non-ReadChunk response and the
  marshaller's tracking map does not grow without bound.
- If a sendCommand validator throws, the response is released in a finally
  block before the exception propagates.

Mirrors the existing server-side request-side zero-copy pattern in
GrpcXceiverService.bindServiceWithZeroCopy.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant