Monday, August 20, 2018

Exploring MassTransit InMemory Scheduled Messaging using RabbitMQ and .NET Core

On this post, let's explore MassTransit's scheduler messaging system using RabbitMQ

On a previous post, I demoed how to create a MassTransit client/server application using RabbitMQ, .NET Core and Linux. Today we will explore another very interesting functionality: the ability to schedule messages to send them in the future. My experiences with MassTransit so far have been fantastic, however, there are a few use cases that I still would like to test. On this post, we cover the scheduled message use case, testing the in-memory solution.

Persistence Requirements

In order to keep our data persisted for the scheduler to use we'll need to configure MassTransit's storage with one of the following services:
  • Quartz.Net in a hosted server
  • Azure Service Bus
  • RabbitMQ by installing a plugin
  • a test-driven In-Memory implementation
On this post, we'll spike out the in-memory solution due to its simpler requirements but the behaviour should be equivalent for different transports.

Referencing Packages

MassTransit's Scheduling Api utilizes Quartz.Net. So, for it to work, we will need the to add a reference to the MassTransit.Quartz package to your project with:
$ dotnet add reference <project-name> MassTransit.Quartz --version 5.1.3
Once the reference is added, run dotnet restore to load the necessary extension methods to do the initialization.


The initialization code for the in-memory implementation as simple as adding a call to UseInMemoryScheduler() on your bus configuration.
Using the in-memory scheduler uses non-durable storage. If the process terminates, any scheduled messages will be lost, immediately, never to be found again. For any production system, using a standalone service is recommended with persistent storage.

Sample Code

The code below shows a simple implementation of MassTransit and its scheduling system:

Running the Demo app

So, I run my app and my code schedules a message to be sent 3 seconds after sent by the user. This is my output:


Hope this serves as an introduction to the scheduling feature within MassTransit. I've been using MassTransit for a couple of years now and definitely would recommend it as a framework for your distributed systems. Want to learn more about MassTransit? Please consider reading the following posts:

    Source Code

    The source for this post is located on my GitHub page.
    In case you're interested, I recently pushed a more updated MassTransit/Docker/.NET Core 3.1 implementation to GitHub here:

    See Also

      For more posts about MassTransit, please click here.

      About the Author

      Bruno Hildenbrand      
      Solutions Architect, Software Engineer and open-source enthusiast.
      .NET, Azure, Go, Linux, Vim, Fedora, i3, Development and Architecture.