When we started working on our Obsidian Scheduler, one of the primary motivations was to give our clients full control over the configuration of their server runtime and total control over job configuration, including schedule, state, parameterization, etc. More than just full control, we wanted the configuration of said items to take effect immediately across all instances, without the need for restarts and without any necessary code or config file changes.
The established means of handling this is having a user interface that fronts the configuration items. But many scheduler solutions including cron4j, default Quartz and Spring’s simple scheduler support do not anticipate needs beyond the scheduling of a job. Even from a development perspective, a developer would reap productivity gains from not having to to crack open code or config files, stop and start the server runtime to make these types of changes and have them take immediate effect.
Liveness of these changes across all running scheduler hosts is accomplished using a single data store to store/view the configuration, ensuring proper concurrency safety to avoid dirty writes, deadlocks and the like. As previously discussed on this blog, using an optimistic locking strategy globally has negligible impact on performance while protecting against dirty writes. By choosing such for Obsidian and making strategic use of pessimistic locks, semaphores and reentrant locks, we can handle 1000s of concurrent jobs and dozens of concurrent hosts on minimal hardware without collisions or failures.
One of the the great features of Obsidian is its administration user interface. A webapp that can run with or without and embedded scheduler instance, this is the control panel, if you will, of your scheduler pool and your runnable jobs.
Here are some examples of configuration items that you can control from Obsidian Scheduler’s Admin UI and whose changes take effect immediately across all pooled instances.
- Job State – including disabling/enabling a job
- Job Schedule – cron pattern
- Future State/Schedules – e.g. disable a job at midnight tomorrow or change a job to run hourly as of next week
- Job Parameters
- The script itself in Script Jobs
- Scheduling a job
- Remove a running host from the pool – Without shutting it down
- Job Chaining
- Job Conflict Configuration – including prioritization
A convenient byproduct of putting all this management control in an interface is that it is very easy to have a group of people have read-only access (e.g. production support) to these configuration items. Obsidian does just that, including a read-only role in both native DB and LDAP controlled modes. Server-level controls are also exposed in Obsidian’s admin interface, secured to the admin role. These items provide fine-grained control over advanced Obsidian Scheduler features.
I’ve mentioned the Obsidian pooling support in passing several times in this post. This is another hallmark feature of Obsidian Scheduler. In our next post, we’ll discuss what makes this feature so special.