QueryHost claims the Context trace id on the outbound request - #774
Merged
Merged
Conversation
When an edge component builds a new outbound message, its natural trace id differs from the inbound transaction's. QueryHost now sets the Context's TRACE_ID as the message's claim when it has none, so the outbound send event carries the inbound id as trace-claimed and the two legs link. An existing claim is left alone. Closes #773
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.
Implements #773. Follow-up to #769.
What
Before handing the request to the MUX, QueryHost sets the Context's
TRACE_IDas the message's claim when the message has no claim of its own, the same patternSendResponseuses for the response. An existing claim is left alone; a Context without a trace id leaves the message untouched.Why
When QueryHost forwards the inbound request unchanged, the outbound leg already shares the inbound trace id through the content-derived natural id. When an edge component builds a new outbound message (different STAN, TID, MID or format), that message has its own natural id and the leg was a separate trace. With the claim, BaseChannel stamps the outbound send event with the leg's id as
trace-idand the inbound id astrace-claimed, which links the two.The host's response receive event still carries only the leg's id, since the claim cannot reach it before the receive event is emitted. The TM event contains the response and the leg's send event carries
trace-claimed, so the join is two hops. Stamping the response itself needs an id on the wire (CMF 113.22 filter, separate).Custom participants that build their own outbound message should apply the same lines.
Tests
Three cases added to
QueryHostTest: claim set from the Context (and carried by the cloned response), existing claim left alone, no trace id in the Context. Full:jpos:testand:jpos:javadocpass.