Open Hadryan opened 1 year ago
BlazingMQ supports temporal isolation of producers and consumers in its major modes (priority and fanout). It buffers messages until they can be delivered. You can specify byte and message quotas, and time to live. There are no artificial limits on those values. Given sufficient disk space, BMQ will happily store millions of messages for years.
To clarify the use case here, are you asking for the ability to specify on the message when you push it to the queue a point in time which it should not be delivered to a consumer before?
e.g. Don't deliver this message before Midnight December 31st 2030 UTC, even if there is a consumer subscribed to the queue?
Or just that you want to push messages into the queue with no consumers, and only add consumers at some point in the distance future?
@willhoy: I was asking for the first scenario. However, now, I'm also interested in the second case, since there might be scenarios like this and that would be great to have a solution ready.
Don't deliver this message before Midnight December 31st 2030 UTC
Regarding this (first) scenario, something similar might be simulated with subscriptions:
deliver_after
to its messages, the value of this property might be either ISO string representing time or just integer UTC seconds from the start of the epoch (careful with int32 if you decide to use it here, there is a year 2038
problem with UTC seconds).deliver_after <= [current date/time]
, with some concrete date: deliver_after <= 2023-08-05T12:00:00
for example. This will flush all the messages needed to the consumer.[current date/time]
periodically.This solution has some downsides:
With subscriptions, our goal was to save as much time on evaluation as possible, to achieve high throughput, so we have some limitations to allow algo optimizations:
message
<->subscription
is fixed, once evaluated to true/false, it's guaranteed not to have the other value.Adding some variable parts to subscription expressions (other than message property names) might require some non-trivial work.
On the other hand, there is an interesting idea about triggers - similar to expressions, but living in the message @quarter-note : consumer[subscription] -> queue [message_1, ..., message_N] consumer -> queue [message_1[trigger_1], ..., message_N[trigger_N]]
Trigger is an expression which can be checked periodically or on some events, for example, when some variable changes. Need to know possible usage scenarios, not able to think of some variable other than time.
I would not use subscriptions for this. Sounds very hacky. Idea of triggers is interesting, but we need to think about its utility. What are some of the problems that we are looking to solve with triggers?
Is there an existing proposal for this?
Is your feature request related to a problem?
Problem is for very long delayed queue.
Describe the solution you'd like
Delayed message queue that can hold millions of messages for long enough (e.g. 365 days), and persistent is required.
Alternatives you considered
With rabbitmq and delayed message queue plugin it's possible to achieve that partly, mostly because of limitations in mnesia.