[rabbitmq-discuss] Scheduled/postponed messages
jon at jbrisbin.com
Mon Apr 25 15:53:18 BST 2011
On Apr 25, 2011, at 9:47 AM, Konstantin Tjuterev wrote:
> So, until this feature is implemented, which strategy do you think would be best as a workaround?
This is completely off-the-cuff, but by using the new Riak RabbitMQ postcommit hook, you could store your messages in Riak first with the "ignore" flag set to true. At 8:00 a cron job could simply roll through all the entries in that bucket and turn off the ignore flag, which would cause all those messages to be sent out at once.
> On Mon, Apr 25, 2011 at 4:58 PM, Jon Brisbin <jon at jbrisbin.com> wrote:
> This sounds to me like the function of a queue type that buffers messages until a specific threshold is reached (either of number or of time window). Ideally, this should be implemented in the broker.
> That wouldn't be an immediate fix, unfortunately, as implementing a new queue type is non-trivial.
> On Apr 25, 2011, at 6:02 AM, Konstantin Tjuterev wrote:
> > Hi, I'm trying to implement the following scenario with RabbitMQ:
> > - a site which generates various emails according to user actions (like registration, ordering etc.), or according to schedule (daily announcements); emails are published into an RabbitMQ exchange
> > - a set of workers which read the queue and send out emails, do some logging
> > - some emails need to be sent immediately
> > - some should be sent precisely at specific time (or as close as possible), like daily announcement should go out exactly at 8:00AM
> > - generating daily announcements involves complex logic and takes some time (more than actual delivery), so there is a job which prepares it before time X and publishes into an exchange
> > So, my question is if there is a native way to schedule messages to be delivered to workers exactly at specific time? If there is not, which strategy do you think would be the best:
> > - declaring a separate queue for such scheduled/postponed messages and starting workers at required time (by cron)
> > - having a check-what-time-is-it/sleep cycle in the workers (which are always running)
> > - having workers consume the message, check time and do NOT send acknowledgement if it's not yet the time to process it (this is the only strategy I see, NOT requiring separate workers, but it will use a lot of resources for retrying message delivery)
> > - anything else?
> > Thanks in advance,
> > Konstantin.
> > _______________________________________________
> > rabbitmq-discuss mailing list
> > rabbitmq-discuss at lists.rabbitmq.com
> > https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
> Jon Brisbin
> Twitter: @j_brisbin
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rabbitmq-discuss