Quartz 4

135_Message_Routing

3 min read

Message Routing

When you publish a message using IMessageBus or IMessageContext, Wolverine uses its concept of subscriptions to know how and where to send the message. Consider this code that publishes a PingMessage:

public class SendingExample
{
    public async Task SendPingsAndPongs(IMessageContext bus)
    {
        // Publish a message
        await bus.SendAsync(new PingMessage());
    }
}

snippet source | anchor

Routing Rules

::: info There are some special message type routing for some Wolverine internal messages and the Marten event forwarding through its IEvent<T> wrappers. Because of course there are some oddball exception cases. :::

When sending, publishing, scheduling, or invoking a message type for the first time, Wolverine runs through a series of rules to determine what endpoint(s) subscribe to the message type. Those rules in order of precedence are:

  1. Is the message type “forwarded” to another message type? If so, the routing uses the destination type. See message forwarding for more information.
  2. Are there any explicit routing rules that apply to this message type? If so, use only the subscriptions discovered from explicit rules (as explained in a following section).
  3. Use a local subscription using the conventional local queue routing if the message type has a known message handler within the application. This conventional routing to local queues can be disabled or made “additive” so that Wolverine also applies other conventional routing.
  4. Any registered message routing conventions like the Rabbit MQ or Amazon SQS routing conventions or a user defined routing convention.

Diagnostics

There’s admittedly a lot of switches and options for message routing, and it’s quite possible that the actual behavior could be confusing, especially with unusual configuration usages. Not to worry (too much), because Wolverine gives you a couple options to preview exactly what the subscriptions are for a given message type you can use to check your understanding of the Wolverine configuration.

Programmatically, this code shows how to “look” into the configured Wolverine subscriptions for a message type:

public static void PreviewRouting(IHost host)
{
    // In test projects, you would probably have access to the IHost for 
    // the running application
 
    // First, get access to the Wolverine runtime for the application
    // It's registered by Wolverine as a singleton in your IoC container
    var runtime = host.Services.GetRequiredService<IWolverineRuntime>();
    
    var router = runtime.RoutingFor(typeof(MyMessage));
    
    // If using Wolverine 3.6 or later when we added more
    // ToString() behavior for exactly this reason
    foreach (var messageRoute in router.Routes)
    {
        Debug.WriteLine(messageRoute);
    }
    
    // Otherwise, you might have to do this to "see" where
    // the routing is going
    foreach (var route in router.Routes.OfType<MessageRoute>())
    {
        Debug.WriteLine(route.Sender.Destination);
    }
}

snippet source | anchor

First, you can always use the command line support to preview Wolverine’s known message types by using:

dotnet run -- describe

You might have to scroll a little bit, but there is a section that previews message subscriptions by type as a tabular output from that command.

::: tip The command line preview can only show subscriptions for the message types that Wolverine “knows” it will try to send at bootstrapping time. See Message Discovery for how to better utilize this preview functionality by “telling” Wolverine what your outgoing message types are. :::

For a more focused look at a single message type — including an explanation of why it routes the way it does — use the describe-routing command :

Graph View