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.

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:

Conclusion

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:

• MassTransit, a real alternative to NServiceBus?
• Creating a MassTransit client/server application using RabbitMQ, .NET Core and Linux
• Async Request/Response with MassTransit, RabbitMQ, Docker and .NET core

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: https://github.com/hd9/masstransit-rabbitmq

See Also

• My journey to 1 million articles read
• Adding Application Insights telemetry to your ASP.NET Core website
• Async Request/Response with MassTransit, RabbitMQ, Docker and .NET core
• Creating ASP.NET Core websites with Docker
• Send emails from ASP.NET Core websites using SendGrid and Azure
• Distributed caching in ASP.NET Core using Redis, MongoDB and Docker
• Hosting NuGet packages on GitHub
• Configuration in .NET Core console applications
• How to build and run ASP.NET Core apps on Linux 
• How to create a Ubuntu Desktop on Azure
• Monitor ASP.NET applications using Application Insights and Azure Alerts