hutiefang76 opened a new issue, #3869:
URL: https://github.com/apache/parquet-java/issues/3869
### Describe the bug
`ByteBufferInputStream.read(ByteBuffer)` changes the destination differently
depending on whether `wrap` receives one source buffer or several. The
single-buffer implementation flips the destination after copying, resetting its
position to zero and shrinking its limit. The multi-buffer implementation
advances the position and preserves the limit.
That makes ordinary append reads depend on how the source was split: a
caller that pre-fills a prefix, reads more bytes and flips once to consume the
assembled content works with multiple source buffers but not one.
Reproduced on current master, db9e610, with Microsoft OpenJDK 17.0.18:
```java
ByteBuffer out = ByteBuffer.allocate(8);
out.put((byte) 9);
ByteBufferInputStream in = ByteBufferInputStream.wrap(ByteBuffer.wrap(new
byte[] {1, 2}));
int copied = in.read(out);
// copied == 2, but out.position() == 0 and out.limit() == 3
```
With the same two source bytes split across two buffers, `copied == 2`,
`out.position() == 3` and `out.limit() == 8`, leaving the prefix and space for
another append intact.
A regression matrix through both public `wrap` overloads covers partial/full
copies, prefilled destinations, successive appends, heap/direct/sliced
destinations, a full destination, and end of stream. On the unmodified source,
all 12 single-buffer cases fail and all 12 multi-buffer controls pass, with no
test errors or skips. At EOF the single-buffer read also returns 0 instead of
-1, and a zero-space read flips the destination despite copying nothing.
I am preparing a focused fix to align the single-buffer path with the
multi-buffer path: advance the destination position by the copied count, keep
its limit, and leave it unchanged for zero-space/EOF reads. I will document
that behavior on the public method and include the regression test. This does
not touch the slab-position issue discussed in #3712.
### Component(s)
Core (`parquet-common`).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
