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
CompositeByteBuf.component()
returns ByteBuf duplicates without adjusting the indexes
#12844
Comments
@chrisvest can you have a look ? |
As I understand it, the essence of the issue is that We can ask ourselves if getting a component buffer out of a composite buffer is the dual of adding, or if it's only the readable contents of the buffers that matters. As far as I can see, tests and documentation don't say either way, but I'm hesitant to change this for compatibility. We can update the javadoc to say that the component indices do not reflect the indices of the composite buffer. @sergiitk How does that sound? Would you be interested in contributing such a PR? |
Hey @chrisvest. Yes, I was going to make the PR soonish. Regarding what approach to choose - I'll follow up later, need to dig a bit more first. |
Expected behavior
Removing a component from a CompositeByteBuf, and adding it back to the same place does not change the content of the CompositeByteBuf.
Actual behavior
In certain cases, removing a component from the CompositeByteBuf, and adding it back results in the CompositeByteBuf with the content different from before the removal. In such cases,
CompositeByteBuf.component()
returns a buffer with the reader index out-of-sync with the readable portion of the buffer contributing to the CompositeByteBuf.Steps to reproduce
This corresponds to the code example in the next section.
CompositeByteBuf
with a single component, content:---01234
; read first 3 bytes:CompositeByteBuf
:Note that now the full view of the buffer is the same as the readable portion, as
addFlattenedComponents
made the adjustments to exclude the bytes already read (---
).CompositeByteBuf.component(0)
:Note that the component still contains the bytes discarded by the
CompositeByteBuf()
. This contradicts to what's returned byinternalComponent()
, which returns theslice()
under the hood:What's even more interesting, if we call
.duplicate()
on the slice, it'll return the full view of the buffer, and with correctly offset indexes!Actual
Expected
Minimal yet complete reproducer code
Netty version
4.x
JVM version (e.g.
java -version
)Any
OS version (e.g.
uname -a
)Any
Misc
This is the root cause for the initial rollback of NettyAdaptiveCumulator in gRPC (grpc/grpc-java#7532).
Now that we found the issue, we're bringing back the NettyAdaptiveCumulator in grpc/grpc-java#9558, but using a hack with copying the indexes from the
internalComponent().duplicate()
. This issue is to track the fix in the upstream.cc @ejona86 @normanmaurer
The text was updated successfully, but these errors were encountered: