4

I have been working quite a bit with Rebus lately and so far it has been great.

One area of concern is when we have thousands or hundreds of thousands of messages that are being processed and a dependent service, like the database or RabbitMQ, is down.

In that case, we do not want all of the messages in the error queue. I would like to know if Rebus has any kind of built-in circuit-breaker mechanism? Something like I reach a 10% failure rate threshold over a period of 60 seconds and want to disable the endpoint for a set period of time in case the infrastructure is down and needs to recover.

Rob Packwood
  • 3,698
  • 4
  • 32
  • 48

2 Answers2

3

Dude, that's a brilliant idea!

It could even be made without touching the internals of Rebus, simply by hooking a decorator into the IErrorHandler, which would detect the error rate and then set the number of workers to 0 for a while.

If it's something you're interested in, you can raise it as an issue on GitHub.

mookid8000
  • 18,258
  • 2
  • 39
  • 63
  • I will raise it as an issue on GitHub. MassTransit has a circuit-breaker pattern similar to what I spelled out in my question, but overall I am liking the simplicity of Rebus over the hassle of being overloaded with so many complicated areas of MassTransit – Rob Packwood May 28 '20 at 19:15
  • Quick question here based on your response. I am trying to write my own IErrorHandler implementation for this. Was that what you're suggesting? If so, I can Register it or Decorate it in the options of the rebusConfigurer. However, I still would like the messages to go into the error queue using the default PoisonQueueErrorHandler that is configured. Once I register or decorate my IErrorHandler instance though, I lose the messages since the PoisonQueueErrorHandler ends up not being used. Is there a way to have both handlers called? – Rob Packwood May 28 '20 at 20:54
1

Seems like there is a plugin available

https://github.com/rebus-org/Rebus.CircuitBreaker

Disclaimer

I was just searching for the same thing and I have no relation to the plugin itself. All credits go to the authors.

devployment
  • 2,121
  • 1
  • 22
  • 33