-
Notifications
You must be signed in to change notification settings - Fork 3.8k
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
netty:Fix Netty composite buffer merging to be compatible with Netty 4.1.111 #11294
Conversation
…ng into a netty composite buffer so that it works with both older versions of netty and netty
…ng into a netty composite buffer so that it works with both older versions of netty and netty
int arrayOffset = composite.internalComponent(tailComponentIndex).arrayOffset(); | ||
if (arrayOffset > 0 && arrayOffset + tail.readerIndex() < tailSize) { | ||
// The tail is a slice of a larger buffer, so we need to adjust the read index. | ||
newTail.setIndex(arrayOffset + tail.readerIndex(), tail.writerIndex()); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
.arrayOffset()
is only available for heap ByteBufs (when hasArray()
returns true). Are the components of the composite always heap ByteBufs?
The javadoc of CompositeByteBuf.internalComponent says that "updating the indexes of the returned buffer will lead to an undefined behavior of this buffer".
Is this solution attempting to update the indexes?
// Because of the way duplicate() works in older netty versions this works. It stops | ||
// working in 4.1.111 because they changed what duplicate returns. | ||
ByteBuf sliceDuplicate = composite.internalComponent(tailComponentIndex).duplicate(); | ||
newTail.setIndex(sliceDuplicate.readerIndex(), sliceDuplicate.writerIndex()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think it's fair to put blame on changes in Netty. It seems that this might have always been violating the API contract of Netty's CompositeByteBuf. The javadoc of CompositeByteBuf.internalComponent says that "updating the indexes of the returned buffer will lead to an undefined behavior of this buffer". That's exactly what happened here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lhotari No, it isn't updating the indexes of the internalComponent
buffer, it is using values retrieved from the internalComponent to update the readerIndex
of the buffer returned by composite.component
. You can see netty/netty#12844 for a description of why this is being done. Note that this has been in place and working for a couple of years.
If you know of a better approach in netty 4 for appending to the existing last buffer in a composite than the approach we are taking, I'd be very interested in it.
… internal and external buffers' writeIndex values.
…omponents that are composites.
…omponents that are composites.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The approach for this change is "CompositeByteBuf.addFlattenComponents()
is broken, so stop using it." Only when using addFlattenComponents()
do the components' readable area not equal the Composite's capacity.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great job figuring out this solution, @larry-safran!
* compose strategies. | ||
* <br><br> | ||
* | ||
* <p><b><font color="red">Avoid using</font></b> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure this phrasing in red font makes a lot of sense here. It's not actionable for the user of this class. If it's for modifying the class itself, should we just note that on mergeWithCompositeTail
method instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It isn't just for mergeWithCompositeTail
. It is for the entire class. So cumulate()
and addTail
are impacted as well.
@ejona86 @larry-safran I see you added "backport" and "release blocker" tags. Could you please share in what versions do you plan to backport this fix and what is ETA for new releases? |
I plan to backport to 1.65 (not yet released), 1.64 & 1.63
…On Fri, Jun 21, 2024 at 10:29 AM Idel Pivnitskiy ***@***.***> wrote:
@ejona86 <https://github.com/ejona86> @larry-safran
<https://github.com/larry-safran> I see you added "backport" and "release
blocker" tags. Could you please share in what versions do you plan to
backport this fix and what is ETA for new releases?
—
Reply to this email directly, view it on GitHub
<#11294 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AZQMCXTKL2CKOXBT3DDJCULZIRPHTAVCNFSM6AAAAABJLFX722VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOBTGE2TONRWG4>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
…4.1.111 (grpc#11294) * Use addComponent instead of addFlattenedComponent and do not append to components that are composites.
…4.1.111 (grpc#11294) * Use addComponent instead of addFlattenedComponent and do not append to components that are composites.
…4.1.111 (grpc#11294) * Use addComponent instead of addFlattenedComponent and do not append to components that are composites.
@larry-safran what is ETA for 1.64.1 to be available in Maven Central? |
I'm actively working on the patch release so it should be available this
week.
…On Tue, Jun 25, 2024 at 10:00 AM Idel Pivnitskiy ***@***.***> wrote:
@larry-safran <https://github.com/larry-safran> what is ETA for 1.64.1 to
be available in Maven Central?
—
Reply to this email directly, view it on GitHub
<#11294 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AZQMCXQ3ZZT6TEEESZUU7GTZJGO2HAVCNFSM6AAAAABJLFX722VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOBZGQ3TCNJXGM>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
…h Netty 4.1.111 (grpc#11294)" This reverts commit 0fea7dd, which broke internal benchmarks (b/350059169).
Change the logic for identifying changes to the read index when merging into a netty composite buffer so that it works with both older versions of netty and netty 4.1.111
Fixes #11284