0

I want to write an application that creates scheduled events at specific times. When the delay elapses the event notifies the application. The scheduled events must not be stored in the application's memory because if the application shuts down all scheduled events will be lost - I do not want to write a custom persistence layer for event scheduling. What system can provide persistent scheduling for my application that will call my application back when each event elapses?

I've been looking at message queues and Redis. I am not interested in Java solutions. The closest solution I found was RabbitMQ. Rabbit messages can be assigned a TTL and placed on a queue that is never consumed. Messages that expire fire DLX messages which can be examined to determine whether the message failed due to TTL expiry. However, messages will not necessarily expire in the correct order due to a caveat applicable to message TTLs whereby the message at the head of the queue will block other messages (with potentially shorter TTLs) from expiring earlier than itself. This caveat means RabbitMQ is unsuitable for this purpose and I cannot find any non-Java message broker that satisfies the requirement for a persistent scheduler.

Does programmable persistent scheduling software exist for Linux?

closed as off-topic by amon, GlenH7, Kilian Foth, gnat, Dan Pichelman Nov 25 '14 at 22:02

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions asking us to recommend a tool, library or favorite off-site resource are off-topic for Programmers as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it." – amon, GlenH7, Kilian Foth, gnat, Dan Pichelman
If this question can be reworded to fit the rules in the help center, please edit the question.

  • The caveat that you mentioned regarding RabbitMQ and dead letter exchanges is solvable. A little bit of googling should help you find the solution. – RibaldEddie Nov 25 '14 at 1:57
2

Does programmable persistent scheduling exist for Linux? Yes.

The at command is designed to execute commands once at a specified time in the future. But caveat emptor. Like cron, Unix's repeating-event scheduler, at has been available essentially forever. But it doesn't get as much attention as cron, and in some quarters it has a bit of a reputation for occasionally forgetting events.

I concur with your choice to not use the time-to-live feature of message routing middleware. Blocking behavior and other likely failure modes make that a depends-on-many-assumptions, probably-fragile approach.

If your application has only a modest number of such future signaling events, and if it can withstand the possibility that an external system might not always signal at the appointed time, farming out to at might make sense. If you have a high volume of future signals, and/or need a very-high-fidelity / guaranteed delivery, consider bringing that feature in under your own development and control. If you store your event records in a standard, proven persistence manager (e.g. RDBMS), the "fire event" logic is straightforward.

  • I've never come across any DB that can fire application events. Also I'd quite happily use a message broker if any of them supported scheduling properly. – Quolonel Questions Nov 24 '14 at 23:53
  • It's not the DB that is firing application events. The DB would be doing the heavy lifting--persistent storage and transactional management of the events--but would require your own event loop. – Jonathan Eunice Nov 25 '14 at 0:20

Not the answer you're looking for? Browse other questions tagged or ask your own question.