Skip to content
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

Merged
merged 15 commits into from
Jun 20, 2024

Conversation

larry-safran
Copy link
Contributor

@larry-safran larry-safran commented Jun 15, 2024

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

…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
@larry-safran larry-safran marked this pull request as ready for review June 15, 2024 00:26
@larry-safran larry-safran changed the title Fix Netty composite buffer merging to be compatible with Netty netty:Fix Netty composite buffer merging to be compatible with Netty Jun 15, 2024
@larry-safran larry-safran changed the title netty:Fix Netty composite buffer merging to be compatible with Netty netty:Fix Netty composite buffer merging to be compatible with Netty 4.1.111 Jun 15, 2024
@larry-safran larry-safran added the TODO:backport PR needs to be backported. Removed after backport complete label Jun 15, 2024
Comment on lines 174 to 178
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());
}
Copy link

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?

Comment on lines 169 to 172
// 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());
Copy link

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.

Copy link
Contributor Author

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.

@ejona86 ejona86 added the TODO:release blocker Issue/PR is important enough to delay the release. Removed after release issues resolved label Jun 17, 2024
Copy link
Member

@ejona86 ejona86 left a 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.

Copy link
Member

@sergiitk sergiitk left a 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>
Copy link
Member

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?

Copy link
Member

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.

@larry-safran larry-safran merged commit 0fea7dd into grpc:master Jun 20, 2024
13 checks passed
@idelpivnitskiy
Copy link

@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?

@larry-safran
Copy link
Contributor Author

larry-safran commented Jun 21, 2024 via email

larry-safran added a commit to larry-safran/grpc-java that referenced this pull request Jun 21, 2024
…4.1.111 (grpc#11294)

* Use addComponent instead of addFlattenedComponent and do not append to components that are composites.
larry-safran added a commit to larry-safran/grpc-java that referenced this pull request Jun 21, 2024
…4.1.111 (grpc#11294)

* Use addComponent instead of addFlattenedComponent and do not append to components that are composites.
larry-safran added a commit to larry-safran/grpc-java that referenced this pull request Jun 21, 2024
…4.1.111 (grpc#11294)

* Use addComponent instead of addFlattenedComponent and do not append to components that are composites.
larry-safran added a commit that referenced this pull request Jun 21, 2024
…4.1.111 (#11294) (#11304)

* Use addComponent instead of addFlattenedComponent and do not append to components that are composites.
larry-safran added a commit that referenced this pull request Jun 21, 2024
…4.1.111 (#11294) (#11303)

* Use addComponent instead of addFlattenedComponent and do not append to components that are composites.
larry-safran added a commit that referenced this pull request Jun 21, 2024
…4.1.111 (#11294) (#11302)

* Use addComponent instead of addFlattenedComponent and do not append to components that are composites.
@larry-safran larry-safran deleted the i_11284 branch June 21, 2024 23:53
@ejona86 ejona86 removed TODO:backport PR needs to be backported. Removed after backport complete TODO:release blocker Issue/PR is important enough to delay the release. Removed after release issues resolved labels Jun 24, 2024
@idelpivnitskiy
Copy link

@larry-safran what is ETA for 1.64.1 to be available in Maven Central?

@larry-safran
Copy link
Contributor Author

larry-safran commented Jun 25, 2024 via email

zhangkun83 added a commit to zhangkun83/grpc-java that referenced this pull request Jul 9, 2024
…h Netty 4.1.111 (grpc#11294)"

This reverts commit 0fea7dd, which
broke internal benchmarks (b/350059169).
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.

grpc-netty breaks with Netty 4.1.111.Final
6 participants