Exp backoff

[dwkoogt]

Tried creating an exponential backoff retry handler that can be configured same way as the Maxretry handler. I have wrote about it in this blog post.

[michaelklishin]

@gabrieljoelc thoughts on this? It can be useful but exponential backoff also can be confusing to both humans and monitoring systems. Should we provide such implementation given that it can be provided in the user code?

[gabrieljoelc]

I've contemplated the same thing for a while. I need to spend some time reviewing and see if it's extendible/configurable enough to match up with my existing use case. 😛

[michaelklishin]

@gabrieljoelc did you get a chance to investigate this? :) We recently introduced a similar (pluggable) feature in the RabbitMQ Java client, so unless the exponential back-off behavior is forced on everyone, I'm a lot more open to it now. It's still damn hard to reason about it when you watch it in action, though :/

[gabrieljoelc]

@michaelklishin I didn't get a chance yet and I'll be hard-pressed to find the time right now.

@dwkoogt this may be a bit much to ask, but would you be open to comparing this other backoff handler to discuss commonalities?

[dwkoogt]

@gabrieljoelc hi. The other backoff handler uses a different approach and setup. It uses per message expiration where expiration time is a constant * (2** num_failures). I've looked into using that but didn't because the rabbitmq doc says "When setting per-message TTL expired messages can queue up behind non-expired ones until the latter are consumed or expired." (https://www.rabbitmq.com/ttl.html).

[gabrieljoelc]

This does look good. Can you add some documentation with some examples of resulting queue structures/names please?

[gabrieljoelc]

Thank you for contributing and for doing the additional research for me!

@michaelklishin I'm good with this. What do you think?

[abepetrillo]

Might be worth looking at the sneakers_handlers as well