SwiftMQ is a micro-kernel based JMS 1.1 enterprise messaging platform. Version 4.5 adds a new enterprise-class Scheduler Swiftlet as an integral part of the standard distribution, many predefined jobs, online backup, system queue controllers, and more.

Check out SwiftMQ:

http://www.swiftmq.com/products/router/releasenotes/index.html

More info
----------------
SwiftMQ 4.5.0 now integrates a job scheduler to run jobs at a specific time of a day or in repeat intervals, based on stackable calendars.

You can schedule a backup of your message store every day at 11pm or move the content of a queue every 2 hours on business days, except company holidays, to a remote queue on another router. Define a job to start a routing connector at a specific day time for 30 minutes. Etc, etc...

You can even run your own jobs. SwiftMQ provides an application invoker job that invokes an embedded Java application on your schedule. This enables you to
create schedulable jobs without the need to implement any proprietary interface. It’s just a Java application. No vendor lock-in!

Features of the Job Scheduler:

- Enterprise job scheduler to run jobs on base of a schedule.
- "at" and "repeat" schedules.
- Configurable stackable calendars.
- Many predefined jobs, like backup, routing connector, queue mover, etc
- Can schedule any Java application as a job. No need to implement proprietary interfaces. No vendor lock-in!
- Schedules can be programmically created and removed by any JMS client (e.g. schedule a message for later delivery).
- Powerful job monitoring.

Further enhancements are:

- Online backup of the persistent store (schedulable as a job)
- System queue controllers
- and more

Check out:

http://www.swiftmq.com/products/router/releasenotes/index.html

Most of scheduler use "direct" mechanism and work well. What advantages you get
from "indirect" (asynchronous) mechanism to justify the overhead you get from
"indirect" mechanism?

Another question: if a job scheduled at 2:00PM and at that time the JMS server
is down. The JMS server is up and running again at 3:00PM. When the job will be
executed? Can you guarantee a job will be run at the scheduled time and be run
ONLY once?

> from "indirect" (asynchronous) mechanism to justify the overhead you get from
> "indirect" mechanism?

SwiftMQ's scheduler works direct. It executes a job, e.g. an embedded Java app or any predefined job. Do you mean to schedule messages from a JMS client as "indirect"? Well, that's just one possibility if a JMS server is combined with a scheduler. For example, a client can't process a message yet and schedules it to be redelivered 2h later. And so on.

> Another question: if a job scheduled at 2:00PM and at that time the JMS server
> is down. The JMS server is up and running again at 3:00PM. When the job will be
> executed? Can you guarantee a job will be run at the scheduled time and be run
> ONLY once?

No. How? If the scheduler is down, it cannot process the job. No scheduler can do that, except it has some secondary that takes it over. Jobs aren't refired if an invocation time was missed. If the time has gone, the next time is choosen. However, since any SwiftMQ router contains a Scheduler Swiftlet, you can use any of them in a federated router network to schedule a job, e.g. one which will not go down. ;-)

The intention of SwiftMQ's scheduler was to make many of SwiftMQ's internal tasks schedulable, e.g. a backup, a routing connection to another router each business day from 9-5, activating a JavaMail or JMS bridge at a specific time, moving queue contents to a remote router. Stuff like this. Further, it should enable JMS clients to schedule messages. And, important, it should be able to invoke arbitary [embedded] Java apps as a job. This was the design goal.

I've evaluated some other schedulers and even considered to use one of them as the base for ours. However, at the end, it was better to write a clean integrated scheduler by ourself. They provide some nice exotic features, however, check if a simple thing like a max. runtime (which we need) is possible or whether they can use threadpools instead of using a thread waiting that the run method of the job ends.

-- Andreas

Will the execution time of jobs be accurate or whatever delay?
how to deal with load balance?