Adding Durability to Senders or Listeners

To add durable messaging behavior to any kind of endpoint (), use the Durably() method to tag any listener or publishing point as durable as shown below:

public class DurableTransportApp : JasperOptions
    public DurableTransportApp()
            .ToServerAndPort("server1", 2201)

            // This applies the store and forward persistence
            // to the outgoing message

        // Set up a listener (this is optional)

            // This applies the message persistence
            // to the incoming endpoint such that incoming
            // messages are first saved to the application
            // database before attempting to handle the
            // incoming message


This sample uses the built in TCP Transport, but the durability option is available for any supported Jasper transport including the Local Worker Queues.

See the blog post Durable Messaging in Jasper for more context behind the durable messaging.

Consider this sample Ping/Pong Jasper sample application that uses the the lightweight, fire and forget TCP Transport. The sample application include a Pinger system that sends "ping" messages to a second Ponger system, which turns around and sends "pong" replies back to the original sender. Without any kind of message persistence, Jasper can successfully send outgoing "ping" messages and the corresponding "pong" replies when both Pinger and Ponger are running and available.

If you need guaranteed delivery of your messages, you might want to opt into Jasper's durable messaging -- even if you're using an external messaging service like Rabbit MQ or Azure Service Bus.

To see the durable messaging in action, there are a pair of sample applications in GitHub that implement the very same Ping/Pong systems, but this time with durable messaging:

  1. Ping/Pong with Postgresql Backed Persistence
  2. Ping/Pong with Sql Server Backed Persistence

In these examples, you can happily -- and randomly -- stop and start both Pinger and Ponger without any outbound messages getting lost. For any inbound messages that were received but not actually processed some how when the systems are shut down, you will also see those messages get processed by the receiving application when it is restarted.