{{ message }}
Repository navigation
Conversation
The default NettySocketSupport helper always returned null, so Channelz never reported TCP_INFO for open-source users. When netty-epoll is available, read EpollSocketChannel.tcpInfo() via reflection and map all fields into InternalChannelz.TcpInfo. The epoll reflection previously private to TcpMetrics is extracted into EpollTcpInfoAccessor and shared by both callers. Also fix grpc.tcp.recurring_retransmits, which was reading tcpi_retrans (currently unacknowledged retransmitted segments) instead of tcpi_retransmits (number of retransmission timer expirations), which is what the metric is defined to count.
Contributor
Author
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The default
NettySocketSupporthelper has always returnednull(see theTODO(zpencer)inNettySocketHelperImpl), so Channelz never reportedTCP_INFOfor open-source users. When netty-epoll is available, this readsEpollSocketChannel.tcpInfo()via reflection and maps all fields intoInternalChannelz.TcpInfo. grpc-netty does not depend on netty-epoll atcompile time, so reflection is still required. Helpers injected through
InternalNettySocketSupport.setHelperare unaffected.TcpMetricsalready had similar epoll reflection (TcpMetrics.EpollInfo), soit is extracted into a package-private
EpollTcpInfoAccessorshared by bothcallers. All getters are resolved once at class init; if any is missing, epoll
support is disabled as a whole, as before.
Fix:
grpc.tcp.recurring_retransmitsread the wrong fieldWhile doing this, I noticed that
TcpMetricspopulatedgrpc.tcp.recurring_retransmitsfromEpollTcpInfo.retrans()(
tcpi_retrans, the number of currently unacknowledged retransmittedsegments). The metric is defined as "the total number of times the retransmit
timer popped" (unit
{timeout}), which corresponds toEpollTcpInfo.retransmits()(tcpi_retransmits). This PR fixes it to readretransmits(), so reported values for this metric will change.Testing
NettySocketSupportTest: all 29 fields mapped with distinct values; returnsnullfor non-epoll channels, when epoll is unavailable, and when readingfails (e.g. closed fd); plus a loopback test on a real
EpollSocketChannel(Linux only, skipped elsewhere) asserting
state == ESTABLISHED.EpollTcpInfoAccessorTest: verifies every getter name resolves against thereal netty
EpollSocketChannel/EpollTcpInfoclasses (no native loadneeded, runs on any platform).
TcpMetricsTest: migrated to the shared fake; new regression testtracker_recurringRetransmits_usesRetransmitsNotRetrans.