We have a situation with one of our enterprise application that execution path is not instrumenting for the Asynchronous Path (JMS).
Please guide us to understand and resolution, thanks.
Below screenshot is the reference to said issue.
Solved! Go to Solution.
I recommend you to take a look at this other post JMS Async Path Showing Execution Path Not Instrumented. The issue is similar to yours.
On that post there is a recommendation to take a CPU Sampling and see which methods are being executed for this transaction, that might help.
The Execution Path not instrumented simply means that on that particular thread no method was executed that is captured with a Sensor Pack. Once there is at least one method on that thread that is instrumented you will see the details.
For my own experience, I've seen this message when the agent for that execution is out-of-license or uninstrumented for some reason.
No, problem. I can copy the comments from there if you don't mind.
Check the comment from @Christian S.:
there's multiple ways you can receive and handle JMS message, most notably:
onMessage() is pretty easy for us to handle, because we know that handling the message happens exactly in this method and so you will see this method in the PurePath.
receive(), however, is not that simple. this method just returns the message, but the actual handling of the message - which is what you want to see in the PurePath - can happen basically anywhere in a completely different method (or even thread/process/...). this is why there is this mysterious 'JMS Receive Entry Point' Sensor amongst the other KSPs in the dynaTrace Server settings which can/should be modified by the user.
so here comes the tricky part: you (or the customer, his developers, ...) have to figure out which method handles the messages and thus would be a good method to add to this Sensor. as soon as you found one and added it, you should get rid of those 'Execution Path not instrumented' nodes.
For your case I would run a CPU Sampling during the execution of LogbackSessionDataFilter, and see which methods are being executed. After that you can try to instrument those methods.
The result from the other case was:
I did a CPU sampling for this customer, and instrumented 14 customized OnMessage, and now we are able to see a lot deeper, thanks!
Thank you for this favour.
Let me discuss with the developers and I also try to take the CPU Sampling to see the executed methods.
I will keep posting on this to get further assistance.