When I first wrote on this topic, I lamented that the de facto standard for scheduling jobs in Java applications is use of the Quartz scheduling library. Why? At the time, I explained:
- Enabling your application to schedule jobs with Quartz takes significant code and/or configuration.
- Changes in job schedule or other parameters require code/configuration changes with a corresponding software build/test/deploy cycle.
- Quartz is just a library and not a scheduling solution. It has no built-in UI for configuration or monitoring, no useful and reasonably searchable logging or historical review, no support for multiple execution nodes, no administration interface, no alerts or notifications, not to mention buggy recovery mechanisms for failed jobs and missed jobs.
Quartz hasn’t changed much in the two years since I wrote that post. A single minor release and two maintenance releases have done nothing to address its pain points.
It’s true that Quartz has some free or even commercial add-ons to address some of these issues, but these require additional configuration, add complexity to your software environment and are by nature afterthoughts and will never be able to fundamentally change Quartz’ nature – a library. Obsidian Scheduler has been designed from the ground up to address all of these shortcomings and more and is free to use for a single scheduling instance.
Consider some reasons why Quartz could disappoint you should you choose this “standard” for your project.
Scheduling Configuration
Quartz requires code or XML configuration or some combination thereof to schedule jobs. This has multiple drawbacks, the biggest of which is this: verifying your code or configuration changes requires either deploying your software environment in its target environment (WAR, EAR, standalone Spring application, etc.) or some appropriate test harness before finally verifying the results. If there is a severe issue, you must then decipher an API exception message and attempt to make the necessary changes and then restart the verification cycle. This process is long and tedious, especially if you have to make multiple passes to correct issues.
Obsidian on the other hand requires no configuration or code to make scheduling changes or other job execution parameters. These changes are validated and applied in real-time or can even themselves be scheduled ahead of time. You can even see a preview of when jobs will run, so you aren’t left wondering if you got your schedule correct. You are free to do this using the UI or you can use the REST API.
Execution Context
Quartz is a library. This means that it is nothing more than an API. It does not provide an execution context. Why is an execution context important? An execution context is required to interact with your scheduling environment in real-time. Any number of things you might like to do are not possible because of no execution context. Disable a job? Change a schedule? See what jobs are running? Subscribe to scheduling event? Some of these are not possible without an execution context while others are impractical. Even if you have an execution context in your application already, such as Spring, you need to expose the Quartz API functions in your context and then make them available for invocation in some UI or expose them in some new or existing context API.
Obsidian includes an execution context that can either run as standalone or embedded into an existing context (such as Spring). This execution context provides many of Obsidian’s useful features, including clustering, interactive scheduling changes via GUI or REST, real-time monitoring, scheduler pausing (global or host-specific) and so on.
Operational Roles
With Quartz, everything relating to job scheduling becomes a function of the development team. Job failed or didn’t trigger when expected? Developer must investigate in the log files. Scheduling change? Developer must make the change, test it and support pushing the change to the target environments. Need to disable the scheduler? More code changes.
With Obsidian Scheduler, we make it possible to reduce the burden on the development team and allocate functions to more appropriate owners. Developers really shouldn’t have any more access to your live environment than is absolutely necessary. If they do need an access account to Obsidian for support, give them a read-only account that allows them to support the operations and business groups in their work. Or give them the limited-read role if your job configurations contain sensitive information such as IDs or passwords. Business teams or other appropriate designates could be given write access to make job scheduling and parameter changes or submit ad-hoc jobs. Your operations staff can be given the admin role to configure the Obsidian run-time itself (thread pool sizes, system recovery, etc.)
If you’ve ever used Quartz then you’ve likely suffered through these and other issues. Download Obsidian today and experience how productive and efficient job scheduling can be!