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.

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.

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

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.

Thanks. we very much appreciate your candor

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

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.

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.

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.

So from what I understand, this plugin is not mature enough for heavy usage, does this mean that the previous solution which was described as:

" use a mix of message TTL and Dead Letter Exchanges as proposed by James Carr here."

Is more suited for production use with heavy load ?

@rtista I don't know what "heavy usage" means to you but a combination of TTL and dead-lettering have been used in the community for years, including messaging frameworks such as NServiceBus.