-
Notifications
You must be signed in to change notification settings - Fork 867
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
Spring Integration javaagent instrumentation #3295
Spring Integration javaagent instrumentation #3295
Conversation
ext { | ||
// context "leak" here is intentional: spring-integration instrumentation will always override | ||
// "local" span context with one extracted from the incoming message | ||
doNotFailOnContextLeak = true | ||
} |
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.
This is a consequence of always using the context extracted from the incoming message; we completely ignore the "local" current context, but that's fine in that case.
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.
Hmm... our debugContextLeakIfEnabled
should not be called at all in case of CONSUMER
spans. This is not spring integration specific problem.
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's called for all spans, span kind does not matter.
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.
Yes, but the logic of not failing the test should be the same for all CONSUMER
spans.
...pring/spring-integration-4.1/javaagent/src/test/groovy/SpringIntegrationAndRabbitTest.groovy
Outdated
Show resolved
Hide resolved
.../spring/spring-integration-4.1/testing/src/main/groovy/AbstractComplexPropagationTest.groovy
Show resolved
Hide resolved
ext { | ||
// context "leak" here is intentional: spring-integration instrumentation will always override | ||
// "local" span context with one extracted from the incoming message | ||
doNotFailOnContextLeak = true | ||
} |
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.
Hmm... our debugContextLeakIfEnabled
should not be called at all in case of CONSUMER
spans. This is not spring integration specific problem.
...pring/spring-integration-4.1/javaagent/src/test/groovy/SpringIntegrationAndRabbitTest.groovy
Outdated
Show resolved
Hide resolved
...pring/spring-integration-4.1/javaagent/src/test/groovy/SpringIntegrationAndRabbitTest.groovy
Outdated
Show resolved
Hide resolved
After discussing this with @iNikem I've changed the way spans are created by the spring-integration instrumentation:
|
// spring-cloud-stream-binder-rabbit listener puts all messages into a BlockingQueue immediately after receiving | ||
// that's why the rabbitmq CONSUMER span will never have any child span (and propagate context, actually) | ||
// and that's why spring-integration creates another CONSUMER span | ||
span(4) { | ||
name ~/testTopic.anonymous.[-\w]+ process/ | ||
childOf span(3) | ||
kind CONSUMER | ||
} | ||
span(5) { | ||
name "testConsumer.input" | ||
childOf span(3) | ||
kind CONSUMER | ||
} |
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.
Two CONSUMER spans here are a necessity: turns out spring-cloud-stream for rabbitmq uses a listener that puts all incoming messages into a BlockingQueue
immediately after receiving them; there's no way to propagate context through that... (BTW, this explains why @RabbitListener
did not work for some people)
So when spring-integration instrumentation kicks in, it sees no CONSUMER span, so it creates a new one - a child of the remote PRODUCER span.
case SERVER: | ||
suppressed = ServerSpan.fromContextOrNull(parentContext) != null; | ||
case CONSUMER: | ||
suppressed = ServerSpan.exists(parentContext) || ConsumerSpan.exists(parentContext); |
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.
SERVER and CONSUMER spans are now both treated as "local-root" type of spans; by default, you can't have both of them in a single process, in a single trace, since they both represent the receiving side.
This is a pretty significant change, please tell me WDYT.
9434914
to
84bfb99
Compare
} | ||
} | ||
span(5) { | ||
name "testConsumer.input" |
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 think by message semantic conventions this should be testConsumer.input process
} | ||
} | ||
span(3) { | ||
name "testTopic -> testTopic send" |
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 think messaging semantic conventions suggest this should be just testTopic send
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.
That span comes from rabbit instrumentation, do you mind if I create an issue for this?
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 seems that we should review rabbitmq integration's usage of semantic convention anyway. There are some other strange things 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.
attributes {} | ||
} | ||
span(2) { | ||
name "exchange.declare" |
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.
can you comment in the test which spans are from spring integration instrumentation and which are from rabbitmq instrumentation?
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.
Good point, will do.
No description provided.