Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Delay interval predictability #72

Closed
brianbarclay opened this issue Nov 7, 2016 · 9 comments
Closed

Delay interval predictability #72

brianbarclay opened this issue Nov 7, 2016 · 9 comments

Comments

@brianbarclay
Copy link

brianbarclay commented Nov 7, 2016

We have noticed a general issue with the reliability of delayed messages using the x-delay message header and x-delayed-type exchange. Specifically, as the size of the mnesia database grows, delayed messages become gradually more and more delayed.  The delayed message plugin does not respect the delay times in any predictable way. We have some messages that delay 2000 milliseconds, some that delay 900000 milliseconds (15 minutes), and a variety in between. We are seeing messages come through the system as much as 3 days after being queued with an x-delay header of 900000 This behavior is similar both inside a 2-node production cluster, and in our test environment which consists of only a single node. We are able to work around the issue by deleting the mnesia tables, and allowing it to be recreated by the system.

@brianbarclay brianbarclay changed the title Issue with delayed messaging Delay interval predictability Nov 7, 2016
@michaelklishin
Copy link
Member

To how many rows does it grow?

This plugin is often used as if RabbitMQ was a database. It is not. Beyond a certain number of delayed messages the current design is not going to work and this plugin is not a priority for our team at the moment.

@michaelklishin
Copy link
Member

Another source of variability is the fact that this plugin relies on Erlang timers. After a certain number of long lived timers in the system they begin to compete for scheduler resources and time drift accumulates.

@brianbarclay
Copy link
Author

We do not know how many rows, but we believe it gets to be over a million

@michaelklishin
Copy link
Member

I'd not expect this design to support millions of delayed messages. it wasn't created for heavy duty workloads and should not be used as a secondary (leave alone primary) data store for delayed operations.

One day it may be more suitable for those tasks but not today.

@brianbarclay
Copy link
Author

Thanks. we very much appreciate your candor

@JerryChaox
Copy link

What is the best threshold for production, if I limit the growing of delayed message.

@lukebakken
Copy link
Contributor

What is the best threshold for production, if I limit the growing of delayed message

This depends on your environment. Please ask questions on the mailing list in the future.

@lambodar
Copy link

lambodar commented Sep 1, 2019

I understood it's not a DB but at the same time there should be options to configure if not a clarification in doc. It'll save lots of time in capacity planning. It's a question on integrity of rabbitmq.

@michaelklishin
Copy link
Member

We plan to re-architect this plugin. Delay predictability may or may not improve meaningfully as a result, it is an open ended question right now. The limitations of this plugin are reasonably extensively documented.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants