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