The AppDynamics .NET Agent (agent) automatically detects MSMQ backends when an instrumented tier makes a call to MSMQ. MSMQ exit points are methods that publish or push messages to a queue. If you are using NServiceBus over the MSMQ transport, see NServiceBus Backends for .NET.
MSMQ entry points are methods that listen or poll for new messages in the queue. Before the agent can detect entry points or perform downstream correlation for MSMQ you must define the correlation field and, for multithreaded architectures, specify threading architecture.
Exit Points and Backend Naming
The agent names the queue for the queue name returned from the system.
Entry Points
To enable downstream correlation for MSMQ, you must configure the agent.
Define the MSMQ Correlation Field
Register the msmq-correlation-field app agent node property on both the publishing tier and on the receiving tier. Specify the field where the agent will write and read correlation information.
The agent supports the following fields:
- Extension, the default field
- Label
By default, the .NET Agent writes to the Extension field. However, some frameworks built on MSMQ write data to the Extension field. In this case, the Extension field does not work because it is already in use, so you must configure the .NET Agent to write correlation data to the Label field.
Choose a field not in use by your queue implementation. If your implementation uses both the "Label" and "Extension" fields, downstream correlation is not currently possible.
See "msmq-correlation-field" on App Agent Node Properties Reference. For instructions to register a node property, see App Agent Node Properties.
Specify the threading architecture
If your queue implementation uses a multithreaded architecture, you must register the msmq-single-threaded app agent node property to specify the threading architecture. Set msmq-single-threaded to "False" for multithreaded implementations of MSMQ. See "msmq-single-threaded" on App Agent Node Properties Reference. For instructions to register a node property, see App Agent Node Properties.
The threading architecture dictates how the agent calculates the call timing for the message queue:
For single-threaded queues, the agent calculates the call time between receive requests. The call time begins at the end of the first receive method and ends when the next receive method starts.
In the following example, the length of the ProcessMessage() method:
MessageQueue messageQueue;
for(;;)
{
var message = messageQueue.Receive();
ProcessMessage(message);
}
CODE
- For multithreaded queues, the agent does not capture timing.
