NServiceBus: Messages as Singletons

Question

We currently have a Singleton Saga (implemented like here: https://lostechies.com/jimmybogard/2015/04/17/saga-implementation-patterns-singleton/) which is resending a message after a specific timeout.

This works fine, since the respective Handler can catch the Message and do it's stuff. Unfortunately, for example on installation days, the Handler to catch the Messagesis stopped, yet the Saga with its blissful ignorance keeps producing messages. Depending on the time the Handler wasn't around, the queue is full of messages. Since this Messages only trigger a full-load, pretty much only one message per time on the Bus would be enough. I have several possibilities here:

• The easiest one would be to access the Queue (somehow) and check, if the Message is there. From what I've seen though, this is not possible out of the box
• I set a [TimeToBeReceived]-Attribute. This would ease the pain during the Handler-downtimes
• I introduce a State into the Saga. The Handler would have to put a Message on it's own on the Bus, which is then handled by the Saga. This seems like the "Saga"-like approach, but makes it dependent on the Handler

The easiest solution would be to kindahow have the possibility to mark the Message as singleton, but I didn't find any hint, how to do so. The second easiest approach, checking the Queue, also doesn't seem to be that easy with the given Interfaces.

Are there any missing possibilities or is there an approach, which would better fit the mindset behind NServiceBus?

Answer 1

TimeToBeReceived is a good option, but doesn’t help when an endpoint is up and running. Messages won’t have time to expire and will be processed.

The saga approach could work, but that would mean there are message series with some unique identifier for each series. I haven’t seen that in your description.

Given that the processing endpoint can be offline at any point at time, I assume there’s a general kick off message (not unique) sent possibly multiple times, while the endpoint is down. I would have the handler in a separate endpoint and configure that endpoint to discard old messages at startup.That way all messages coming while the endpoint is down will be discarded. There are a few caveats with that.

1. All messages in the queue will be gone. Therefore need to be careful what other messages are sent to the queue.
2. If you want handler to respond to the first message in a series, this won’t work as there’s no way to know if the first message was sent when the endpoint was running or not.

In case the second bullet point is what you’re facing, having a state is unavoidable.