feat: name the subscriber (node + topic) in the UDS send-drop warning… - #18
Open
benaliabderrahmane wants to merge 1 commit into
Open
feat: name the subscriber (node + topic) in the UDS send-drop warning…#18benaliabderrahmane wants to merge 1 commit into
benaliabderrahmane wants to merge 1 commit into
Conversation
… and clarify the byte count
The drop warning printed only the peer's socket path and worded the
message size as if it were the receive-buffer fill level
("recv buffer full (N bytes)"). Both made a slow-subscriber drop hard
to diagnose: the path only encodes a PID, and the byte count looked
like it contradicted the configured buffer size.
Now the ENOBUFS/EAGAIN branch names the offending subscriber by its
fully-qualified node name and topic, states plainly that the number is
the dropped message's size, and shows the configured recv-buffer size
for reference.
The peer label is built once per graph change (make_peer_label) and
stored in the copy-on-write subscriber cache alongside the socket path,
so the publish/wait hot path still copies just a refcount and never
formats a string. send_to takes an optional peer_label; the publisher
and the rmw_wait TRANSIENT_LOCAL replay path supply it, request/response
callers pass none and are unaffected.
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.
… and clarify the byte count
The drop warning printed only the peer's socket path and worded the message size as if it were the receive-buffer fill level ("recv buffer full (N bytes)"). Both made a slow-subscriber drop hard to diagnose: the path only encodes a PID, and the byte count looked like it contradicted the configured buffer size.
Now the ENOBUFS/EAGAIN branch names the offending subscriber by its fully-qualified node name and topic, states plainly that the number is the dropped message's size, and shows the configured recv-buffer size for reference.
The peer label is built once per graph change (make_peer_label) and stored in the copy-on-write subscriber cache alongside the socket path, so the publish/wait hot path still copies just a refcount and never formats a string. send_to takes an optional peer_label; the publisher and the rmw_wait TRANSIENT_LOCAL replay path supply it, request/response callers pass none and are unaffected.