Spring-cloud-sleuth: Sleuth and Spring JMS

[Diagoras]

Hey,

I noticed that Sleuth doesn't seem to automatically work with @JmsListener annotated methods. A previous issue along these lines was closed because Spring Cloud Stream should be used instead. However, Spring Cloud Stream doesn't appear to support JMS yet, and I haven't been able to find a clear timeline for when it will.

Is the advice still to move to Spring Cloud Stream, with no plans for supporting the annotation-driven JMS integration that currently exists? If so, is there a particular reason why Spring Sleuth isn't supporting that transport? And do you forsee any difficulties with a third party providing support instead, with some kind of spring-boot-sleuth-jms-starter autoconfiguration that wraps JMS producers and listeners in spans and passes the span through the JMS headers?

Thanks for your time.

[shakuzen]

Have you seen this project: https://github.com/spring-cloud/spring-cloud-stream-binder-jms? I don't see any recent commit activity, unfortunately, and there is a warning about it being considered "alpha". Also from the issue you linked, there was a Framework issue opened that needs to be fixed before JMS can be instrumented "directly": SPR-14683.

[Diagoras]

Have you seen this project: https://github.com/spring-cloud/spring-cloud-stream-binder-jms? I don't see any recent commit activity, unfortunately, and there is a warning about it being considered "alpha".

Yeah, it doesn't really seem to be an actively developed binder. The Spring Cloud Stream README also says that only the Kafka and RabbitMQ binders are supported and actively worked on, which is why I was surprised that "use Spring Cloud Stream" was the standing advice for those wanting to propagate spans over JMS.

Also from the issue you linked, there was a Framework issue opened that needs to be fixed before JMS can be instrumented "directly": SPR-14683.

Ah, I see. That's unfortunate. If that's the reason why JMS is not currently supported, can we leave this issue open and linked to that framework problem to make clear what's blocking progress and what needs to change before JMS can be directly instrumented? That might prevent future users from making the mistake I did, since it's clear that it's a technical issue preventing this change instead of JMS integration being judged out of scope.

On that subject, what do you think about "indirect" instrumentation, either as part of Spring Sleuth or a separate third party project? Much like how thread pools are instrumented with "TraceableExecutorService", maybe there could be "TraceableJmsTemplate"? It obviously wouldn't help with annotation-driven messaging (using @JmsListener and such), but it might get us part of the way there - at least until SPR-14683 is resolved.

Thanks.

[marcingrzejszczak]

Sure, we can leave this issue open until that one get resolved.

On that subject, what do you think about "indirect" instrumentation, either as part of Spring Sleuth or a separate third party project? Much like how thread pools are instrumented with "TraceableExecutorService", maybe there could be "TraceableJmsTemplate"?

Sure! We want Sleuth to be a very stable library, that's why we don't massively write new features. That's why we highly encourage people to write third party projects cause after they gain popularity we want to merge them back to core (for example that was the case with @NewSpan & @ContinueSpan annotations). For example we will have exactly the same approach with https://github.com/spring-cloud/spring-cloud-sleuth/issues/693 JDBC instrumentation. So my suggestion is to start playing around with this in a third party project and then we can consider merging it into core.

What do you think about this?

[Diagoras]

That sounds good. Thanks.

[Stefku]

Hi there, I just created a pull request for instrumenting methods annotaded with @JmsListener. I forked from branch 1.2.x because we using that one. Is that ok? Do I must consider head as well?

[marcingrzejszczak]

Hello! I've seen your PR. It's ok that you've created it against 1.2.x. I'll have to sit down and analyze it. We could have discussed this before you started working on this but well, now it's too late I guess ;)

[Stefku]

Hi @marcingrzejszczak, yes sorry. But we still can discuss it. Doing the PR was kind of good introduction for my self. So, no time was wasted :)

PS: I didn't saw your post and in the meantime I did a PR against master... decline it if you like.

[Diagoras]

@Stefku Thanks for working on this! Awesome to see @JmsListener annotations being traced.

Unless I'm wrong, though, this only works with receiving messages and not with sending them, and even then only when using an annotated method to receive. Do you think instrumenting JmsTemplate directly might also be valuable? Or should that be handled with a separate issue/PR?

[marcingrzejszczak]

@Diagoras I closed the PR cause it just won't work. If one doesn't read tracing context from messages then the approach will just not work. JmsTemplate instrumentation is for sure valuable, but if one can't continue a trace via @JmsListener then it's difficult to proceed. You can add your comment here - https://jira.spring.io/browse/SPR-14683 that you're interested in adding the hook

[Diagoras]

@marcingrzejszczak Ah, I see. Thanks for looking at it, sorry it didn't work out.

[marcingrzejszczak]

Related - https://github.com/openzipkin/brave/issues/584

[marcingrzejszczak]

Closing this in favour of Brave's issue

[marcingrzejszczak]

Thanks to @adriancole Sleuth 2.1.0 will support JMS out of the box.

[manojpandey23]

Thanks for providing the JMS tracing support. It will be great if we can have some running examples of using @JmsListener.

We are trying to migrate our application to 2.1 and @JMSListener just stopped working after enabling the jms instrumentation. I can see the JMSTemplate is adding the B3 header in Message but DefaultJmsListenerContainerFactory is not able to consume. We also tried with SimpleJmsListenerContainerFactory, I can see the messages consumer but it's complaining the container is not running.

May be I am missing some special configuration. Please suggest

[marcingrzejszczak]

Can you provide a sample that doesn't work for you?

[396191970]

Hello,
have you considered adding jms to 2.0. * Version?
Because our project uses 2.0. * No plans to upgrade to 2.1.0 *.
Thanks for your time.

[codefromthecrypt]

brave project has tests that by default test JMS v2 and it also has a separate integration test to cover 1.1 with the same library.

can you produce something that shows it doesn't work? https://github.com/apache/incubator-zipkin-brave/blob/master/instrumentation/jms/src/test/java/brave/jms/ITJms_2_0_TracingMessageConsumer.java

[396191970]

Thank you for your answer. @adriancole
Perhaps we didn't describe the problem clearly.
We use org.springframework.cloud:spring-cloud-sleuth-core:2.0.0.RELEASE in our project., does not intend to use 2.1.1. Release.
So Do you plan to providing the JMS tracing support on org.springframework.cloud:spring-cloud-sleuth-core:2.0.0.RELEASE

[codefromthecrypt]

oh ok, I didn't understand which 2 you were referring to. Got it.

There is a fair amount of code depending on what you are trying to do. Minimally, you can use the most recent version of brave and configure JMS yourself. This wouldn't necessarily help with spring messaging for example. https://github.com/apache/incubator-zipkin-brave/tree/master/instrumentation/jms

On the topic of backporting to sleuth v2.0, I don't know. I don't know how many releases of 2.0 there are to expect, or if it is only bug fixes at this point. 2.2 will be the focus I suspect with spring boot 2.2 on the way. I would defer to @marcingrzejszczak