Should add support for instrumenting the listeners with parameter as subTypes of javax.jms.Message (i.e. javax.jms.MapMessage)

[gajanan8086]

JMS-Plugin

Existing JMS listeners are instrumented only if the parameter to onMessage is "javax.jms.Message". The "javax.jms.MapMessage" which is also frequently used subType isn't handled yet. We should consider supporting the suptypes of "javax.jms.Message"

SessionAwareMessageListeners from springframework are also widely used. Not having support for that can restrict the usage of jms plugin.

There are few messaging providers who have class names like "QuesSender" for example "TibjmsQueueSender.TibjmsQueueSender" from EMS which aren't supported in the current version.

[eyalkoren]

Thanks for reporting!

Existing JMS listeners are instrumented only if the parameter to onMessage is "javax.jms.Message". The "javax.jms.MapMessage" which is also frequently used subType isn't handled yet. We should consider supporting the suptypes of "javax.jms.Message"

Any MessageListener implementation must declare a method which takes javax.jms.Message as an argument. Can you provide the code of such a non-supported listener as example?

SessionAwareMessageListeners from springframework are also widely used. Not having support for that can restrict the usage of jms plugin.

Looks like we can support that, even though it is not standard JMS.

There are few messaging providers who have class names like "QuesSender" for example "TibjmsQueueSender.TibjmsQueueSender" from EMS which aren't supported in the current version.

Good to know, I worried this may be the case. The class name filtering is very efficient so it's tempting to use, but false negatives is a real problem..
Is this class an implementation of javax.jms.MessageProducer?

[gajanan8086]

Thanks for reporting!

Existing JMS listeners are instrumented only if the parameter to onMessage is "javax.jms.Message". The "javax.jms.MapMessage" which is also frequently used subType isn't handled yet. We should consider supporting the suptypes of "javax.jms.Message"

Any MessageListener implementation must declare a method which takes javax.jms.Message as an argument. Can you provide the code of such a non-supported listener as example?

SessionAwareMessageListener is also a good example. The application listener class is allowed to have any subtype of javax.jms.Message

public interface SessionAwareMessageListener

SessionAwareMessageListeners from springframework are also widely used. Not having support for that can restrict the usage of jms plugin.

Looks like we can support that, even though it is not standard JMS.

There are few messaging providers who have class names like "QuesSender" for example "TibjmsQueueSender.TibjmsQueueSender" from EMS which aren't supported in the current version.

Good to know, I worried this may be the case. The class name filtering is very efficient so it's tempting to use, but false negatives is a real problem..
Is this class an implementation of javax.jms.MessageProducer?

Yes "com.tibco.tibjms.TibjmsQueueSender" does implement javax.jms.MessageProducer

[eyalkoren]

SessionAwareMessageListener is also a good example

I see. SessionAwareMessageListener is not a MessageListener, and not part of JMS. However, I will add support for that. Can you test it?

Yes "com.tibco.tibjms.TibjmsQueueSender" does implement javax.jms.MessageProducer

Good! So I will fix that. Would you say adding the Sender word to the name filter is a good choice, or are you aware of any other implementations that will escape the name filter that currently also includes Message and Producer? The reason I try to insist on it is that in some cases the JMS api jar is used as a global library for the entire container, and without this filter, this instrumentation may have a big impact on application startup time.

[gajanan8086]

SessionAwareMessageListener is also a good example

I see. SessionAwareMessageListener is not a MessageListener, and not part of JMS. However, I will add support for that. Can you test it?
Thanks, I will test it.

Yes "com.tibco.tibjms.TibjmsQueueSender" does implement javax.jms.MessageProducer

Good! So I will fix that. Would you say adding the Sender word to the name filter is a good choice, or are you aware of any other implementations that will escape the name filter that currently also includes Message and Producer? The reason I try to insist on it is that in some cases the JMS api jar is used as a global library for the entire container, and without this filter, this instrumentation may have a big impact on application startup time.

Most of the Messaging use Producer only. In Tibco EMS they use Sender for sending to queue and Publisher for sending to topic. Agree with you on naming filter along with type implementation, but need to support both Sender and Publisher

[eyalkoren]

Thanks for your input. What about Receiver and Subscriber for the receiver matcher? Do you happen to know whether this is required as well?

Also, can you check whether this snapshot build fixes the problem?

[gajanan8086]

Thanks for your input. What about Receiver and Subscriber for the receiver matcher? Do you happen to know whether this is required as well?

Nothing as of now. I think Receiver is at disadvantage that it does not have context i.e. the TraceId sent in the Message by previous component while entering the method. Though the span generated while exiting the receive method helps us link the trace to the upstream component, local tracing for the component is generated against different transaction.

I was also thinking if we should have provision to suppress instrumentation for certain queues/topics. Because JMS is used internally by different individual technical components and user might want to suppress those to avoid noise and monitor performance for end application.
For instance JMS ehcache. We need to think through this.

Also, can you check whether this snapshot build fixes the problem?

Thanks for the build will test it.

[eyalkoren]

You are absolutely spot on about the disadvantage of tracing the receivers this way- it is sub optimal, to say the least. It is probably better than nothing as it at least tells you if and when a message was received. This is a general problem with polling APIs in messaging systems, which is among some other challenges around proper messaging tracing that we are now investigating, which is why we still treat this feature as incubating and make it off by default.

Disabling message-tagging for specific queues/topics sounds feasible, so if useful we should definitely consider. I added it to a JMS enhancement issue - #664.

[eyalkoren]

@gajanan8086 there was an error in the build of the former snapshot, please try this one instead.
Thanks for all the great feedback!

[gajanan8086]

@gajanan8086 there was an error in the build of the former snapshot, please try this one instead.
Thanks for all the great feedback!
Thank you so much for the build, It looks good but seems support for keyword Publisher is not added in the MessageProducer instrumentation. I see only Sender keyword is added