NServiceBus Backends for .NET

Exit Points and Backend Naming

NServiceBus exit points are methods that publish or push messages to a queue from an upstream tier. The agent detects exit points regardless of the NServiceBus version or threading architecture. The agent names the queue for the queue name returned from the system. 

Entry Points in a Single-threaded Architecture

NServiceBus entry points are methods that listen or poll for new messages in the queue. When the message receiver uses a single-threaded architecture, the .NET Agent automatically discovers entry points and correlates downstream activity without additional configuration.

The agent measures the call time from the end of the first receive method to the start of the subsequent receive method. In the following example loop, the length of the ProcessMessage() method:

MessageQueue messageQueue;
for(;;)
{
        // Call timing for previous iteration ends.
        var message = messageQueue.Receive();
        // Call timing begins.
        ProcessMessage(message);
}

Entry Points in a Multithreaded Architecture

For the .NET Agent to automatically detect NServiceBus entry points when the receiver is running a multithreaded architecture, set the nservicebus-single-threaded app agent node property to "false" on the receiver. See "nservicebus-single-threaded" on App Agent Node Properties Reference. For instructions to register a node property, see App Agent Node Properties.

For multi-threaded message receivers, the agent does not capture timing.

Support for NServiceBus 6

The support for NServiceBus version 6 is experimental and may undergo modifications in future releases.

The .Net Agent supports NServiceBus 6 with a queue correlation from a sender exit point to a receiver entry point. The entry and exit point names are based on destination. A destination is the name of a queue or topic that sends or receives the messages. However, an exception exists for multicast dispatches where the agent assigns a static name nservicebus_multicast to the backend. The agent detects exit calls when only one message is dispatched at a time. If several messages are dispatched in a batch, the agent does not detect exit calls.

By default, the entry point instrumentation is enabled and the exit point instrumentation is disabled. To enable the exit point instrumentation, include these configurations in the agent configuration file.

<machine-agent>
       <instrumentation>
        <instrumentor name="NServiceBusV6ExitInstrumentor" enabled="true" />
    </instrumentation>
  </machine-agent>  

"instrumentors": {
        "enable": [ "NServiceBusV6ExitInstrumentor" ]
    }     

Resolve Issues with NServiceBus Backends

References to third parties are for informational purposes only and should not be construed as a suggestion of endorsement or partnership. All rights related to any such references are reserved for the respective owner or party.

• If you are using NServiceBus version 6 and get the following exception mentioning a Cisco AppDynamics .Net Agent assembly.  Your environment might be affected by the NServiceBus AssemblyScanner known issue.
  

  Unhandled exception. System.Exception: Could not load '....some_assembly_name.dll'. Consider excluding that assembly from the scanning.
  ---> System.IO.FileLoadException: Assembly with same name is already loaded    

  CODE
  
  

  To fix the issue, it is recommended to stop NServiceBus AssemblyScanner from unnecessary scanning of Cisco AppDynamics .Net Agent assemblies. You can perform one of the following workarounds suggested by NServiceBus:

  1. Configure exclude rules for Cisco AppDynamics .Net Agent assemblies in your application. See NServiceBus AssemblyScanner specification to know more about assembly scanning and how to exclude assemblies from the scan.

  2. Move Cisco AppDynamics .Net Agent assemblies out of the paths that NserviceBus AssemblyScanner scans. You can choose one of the following options:

     • Your application's working directory is the default scanning path. If your application does not have any specific configuration for NServiceBus AssemblyScanner, ensure that the Cisco AppDynamics .Net Agent assemblies are not in your application's working directory. The best option is to move the assemblies into a nested folder of your working directory. You can also choose to move the assemblies completely out of the working directory.

     • If your application includes a special configuration for NserviceBus AssemblyScanner that scans additional paths or scans of nested folders, it is recommended to move the Cisco AppDynamics .Net Agent assemblies out of these paths. See NServiceBus AssemblyScanner specification to know more about assembly scanning and how to exclude assemblies from the scan.

• If you have NServiceBus version 5 and are not seeing downstream correlation on the receiver, verify the threading architecture on the receiver. Set the nservicebus-single-threaded app agent node property to "false" on the multithreaded receivers.

• Only use the node properties for MSMQ, msmq-single-threaded and msmq-correlation-field, if you are using MSMQ independently of NServiceBus. The .NET Agent does not use MSMQ node properties when discovering and instrumenting NServiceBus over MSMQ transport.
• If you are using NServiceBus version 4, you can disable NServiceBus instrumentation on both the publisher and the receiver:

  • Copy the following Instrumentation element to a child of the Machine Agent element:

    <!--Disable NServiceBus instrumentation-->
       <instrumentation>
         <instrumentor name="NServiceBusReceiveContextInstrumentor" enabled="false" />
         <instrumentor name="NServiceBusPublishExitInstrumentor" enabled="false" />
         <instrumentor name="NServiceBusEntryInstrumentor" enabled="false" />
         <instrumentor name="NServiceBusExitInstrumentor" enabled="false" />
       </instrumentation>

    For more information, see "Instrumentation Element" on .NET Agent Configuration Properties.

  • Configure the publisher and receiver as you would for MSMQ or RabbitMQ.