Rate Limiting Sample with Events

#1

I am using a rate limiting behavior similar to the one in https://docs.particular.net/samples/throttling/#limited-the-pipeline-behavior and have been using it with commands for some time. However, now I’ve started using it in a situation where I want throttle events instead and I get the following warning from NServiceBus:

System.Exception: Best practice violation for message type ‘MyEvent’. Events can have multiple recipients, so they should be published.

This exception is being raised from the last non-brace line in the sample. Is there something I can do to suppress this warning or is there a better way to defer handling events than what is provided in the sample?

Thanks.

#2

I worked around the problem by using sendOptions.DoNotEnforceBestPractices(). Is how I should be doing it or is there a better solution?

#3

Hi Dennis

The sample is written with the intention to throttle commands because we have not come up with a reason so far why you would want to throttle an event. Can you elaborate your use case?

What would make a subscriber not being able to react to an event when it is happening? Could it be that you are modeling something as an event that should be a command (a command in disguise)?

It is correct though that events should not be sent with conventions enabled. But in your case as a subscriber you are essentially turning an event into a command that you send to yourself. In that case disabling best-practices is the right thing to do. Still I’m curious about the use case you are trying to achieve

Regards
Daniel

#4

Hi Daniel,

The component where I would like to rate limit event processing is part of a historical data migration tool that when running without a limit has a negative impact on interactive user performance. In the NServiceBus 3 era, we had some logic that would actually stop the receiving bus during business hours and restart it after the close of business.

The migration is a one-time activity and we haven’t had any customer use it in many years, so we had never upgraded the time-of-day based message processing to newer versions of NServiceBus. Now that we have a customer who might need to use it, I’ve been trying to re-implement similar functionality with NServiceBus 7, and rate limiting seemed like the obvious approach, since we likely can process a small number of messages per second during the day, but we can’t necessarily keep up without impacting interactive users.

As command vs. events – the migration essentially has its own workflow that involves both processing commands and then raising events that lead to additional processing (e.g. a MigrateEntity command, which when processed does some work and publishes an EntityMigrated event, and the EntityMigratedHandler does some additional work). Arguably the process could be changed so that all the event handlers do is send a command, and then at this point you could get away with only throttling commands. However, this migration component is used so infrequently that I’d like to avoid making any larger changes that would then lead to additional testing.

Thanks for your help.

Dennis

#5

Hi Dennis

In that case

is the way to go.

Regards
Daniel

#6

Great, thanks for your help.