Information:

Environment

  • Instrumentation

 

Symptoms

 

Solution

 

Background
dynaTrace is preconfigured to monitor message producers and consumers of the MSMQ messaging framework. This provides the ability to see messages being posted to the queue and see the message being read from the queue by the consumer. However, due to the nature of the MSMQ consumer component, following the rest of the consumer invocation tree cannot be done automatically, and requires a manual configuration step.

This Knowledge Base article describes how to configure those manual steps to provide the ability to continue drilling down in the consumer invocation call tree beyond just the initial message read (Receive()) call.

Problem Statement
A typical consumer code block will look like this.

servercodefunction
{
  Message msg = myQueue.Receive();
  processMessage(msg);
}

Where myQueue.Receive() is the MSMQ call which receives the message, and processMessage(msg) processes the message. We want to be able to follow the call thread onwards into the processMessage(msg) call. Without defining the handler of the message, the call tree will stop at the myQueue.Receive() call.
The problem is that the processMessage(msg) call is user defined and as such there's no way for dynaTrace to automatically determine what method actually processes the message itself. A custom method sensor rule is needed which tells dynaTrace which user defined method performs the function of processMessage(msg) as described in the sample code above.

This code snippet above is of course just an example. It is necessary to determine the name of the method which performs the same functionality as processMessage(msg) above. We will continue to refer to this method as processMessage(msg), however it is important for you to substitute the appropriate method that actually does the processing work within your application.

From within the dynaTrace Client, add a new Method sensor rule for your equivalent of the processMessage(msg) method.
Be sure to Save the new rule and restart the SUD.

You should now be able to drill down fully thru the asynchronous call and into the processor of the message itself.