FAQ

From Obsidian Scheduler
Revision as of 19:45, 7 June 2023 by Craig (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

Some of the most common questions we receive about Obsidian are below. They range from questions about how Obsidian works, to how you go about taking advantage of different features. If you have a question not asked below, feel free to contact us. During business hours, we usually have free support chat available which is linked on the left of the page.

If you are having a specific issue, see Troubleshooting.

What is Obsidian exactly?

Obsidian is a Java-based task/job scheduler. At its most basic level, it allows you to run jobs at certain recurring times, like Quartz or cron4j, but it goes well beyond what either provides. It has native, configuration-free clustering, which provides fail-over and load-sharing. In addition, it provides features like a full UI, job chaining, and event notification which are lacking in other popular schedulers.

Obsidian consists of two main parts - a scheduler service and an admin web application which provides a UI to configure and monitor the scheduler's operation. These two features can be run together or separately (see Getting Started).

How do I set up Obsidian?

Check our Getting Started guide, or email us at our support address.

Is it free?

We grant free single-node licenses which you can use forever free of charge (download here). In addition, you get a second node that you can use for one year free of charge to allow you to evaluate Obsidian clustering.

For additional licenses, including clustering nodes, the cost starts at $649 CAD each. For example, if you want to run a 2-node cluster, after the first year you would need to purchase a single $649 license. This license gives you access to free support and all future versions of the product.

Obsidian also provides other licensing options which can be found on our main site.

Is it open source?

Obsidian is currently not open-source. While we support the open-source movement and have contributed to it, we have chosen not to open-source Obsidian so we could help fund our development and support costs.

What technologies does Obsidian use?

Obsidian is built on Java 1.7, and will run on newer versions as well. The admin web application requires a servlet container, such as Tomcat or Jetty. Obsidian also requires a database such as MySQL or Oracle, where scheduling data is stored. Obsidian has a small set of library dependencies (.jar files), selected to avoid conflicts with our users' own libraries. See Getting Started for details on which versions of servlet containers and database platforms are supported.

Why should I use Obsidian?

Obsidian provides a complete end-to-end solution for job scheduling. Often developers focus on the task in front of them and forget about the long-term costs of operations and maintenance. Job scheduling is about more than task execution - monitoring, recovery, notification, etc. are all crucial features to enterprise- or smaller-level infrastructures.

Obsidian is designed to reduce implementation and operations costs while also facilitating development. Our team's years of experience in the field have helped us pinpoint the common issues organizations have with job schedulers and design a product that eliminates those problems.

How is Obsidian different from Quartz?

Quartz is mainly an embedded jar that provides you with the ability to schedule recurring jobs. Developers have to integrate it into their application and layer on code to do things like event notifications, job chaining, etc. In addition, database usage and clustering require additional configuration and, in our opinion, the available UIs are not complete. Quartz focuses primarily on the job execution side of scheduling, and provides extension points for developers to customize behaviour according to their needs.

Conversely, Obsidian is designed from the ground-up to provide clustering, chaining, a complete UI, event notifications, real-time administration, etc. right out of the box. While Obsidian is also embeddable, it is intended to provide a complete solution to job scheduling, including monitoring, high availability, and recovery. It is designed based on years of industry experience dealing with issues of reliability and operations issues. Obsidian doesn't just make your developers more productive, it eliminates work for your whole IT department by making the information they need to troubleshoot and resolve issues quickly available at a moment's notice.

How does clustering work?

Obsidian's clustering works by coordinating effort of various nodes through a central relational database such as MySQL. Each node periodically attempts to claim its share of work off of a work queue. The algorithm that performs this takes into account how many other nodes are running, and how many jobs need to be run at the current time in order to provide load balancing. That is one key difference in Obsidian since it values load-sharing over second-level precision, since most applications don't require it. Quartz, by contrast, does clustering by having all nodes immediately try to claim a job for execution, which can result in one node claiming multiple jobs while others remain idle.

You can add new cluster nodes at any time and they will automatically join the pool, and the load-sharing and scheduling algorithm will adapt right away.

What's Obsidian's performance like and how does it scale?

Whether you are running a single node or using multiple clustered nodes, Obsidian is very efficient at scheduling and execution. We have successfully run thousands of jobs a minute on basic developer hardware without issue. Typically, our users are running a tiny fraction of that number, and we haven't received any reports of poor performance due to scheduling activity.

It is unlikely Obsidian's scheduling activity will have much of a performance impact, so most of our users are constrained by the resource requirements of their actual job code.

Obsidian can scale to many nodes without significant performance degradation. Most customers use 1 or 2 nodes, but running 10 nodes or more should pose no issue.

How do I get my job application code running in the Obsidian WAR or standalone scheduler?

If you are running a Obsidian as a standalone scheduler, embedded in your application, or in the WAR with scheduling enabled, you need to ensure your application JARs are on the classpath. In the WAR, this means adding your JAR files to the WEB-INF/lib directory. If you are embedding Obsidian, it will already have access to the application's classpath. If running as a standalone scheduler, you will have to add your application JARs to the /lib directory. Note that you must include any JARs that contain your job classes, as well as those that contain dependent code.

If you are running a standalone web application that does not have a scheduler running, you do not have to update its classpath with your compiled jobs, unless you are running a version older than 2.6, but there are steps you need to take which are outlined in Classpath for Building.

How do scripting jobs work?

Just configure your job in the Jobs screen (or use the REST API) by entering the script itself and any configuration parameters. Then, Obsidian will run the script as if it's any other job.

Note that scripts will inherently run slower than Java code, so these are better suited to ad hoc jobs or operations type tasks.

How can I send SMS notifications? I only see email support.

Virtually all carriers provide email addresses which will forward automatically to SMS. For example, in the United States, SMS text messages can be sent by emailing [email protected]. Here is a full listing of SMS gateways.

Why isn't my job showing up?

Out of the box, Obsidian will display any previously scheduled jobs and Obsidian's bundled jobs. You can type in your class name as described in Admin Jobs.

As of Obsidian 2.2.1, you can take advantage of our Spring Integration. Jobs that have been wired into your ApplicationContext will be available in the list.

You can also use Obsidian's classpath scanning as of Obsidian 2.0. Note that for this feature to work, the user account running Obsidian must have read privileges to the WEB-INF directory of Obsidian's deployment directory.

What libraries is Obsidian dependent on?

See Advanced Configuration for dependency details.

How do I deploy changes to my jobs? Can I hotswap JARs?

Yes you can! Job Forking needs to be enabled and configured for your deployed environment(s). Since support in Java for reloading class definitions is too unreliable to offer our users, Obsidian doesn't support it. But you can use the Job Forking feature to benefit from updates to deployed classes. Of course, this is simply for job execution. If the job's configuration support needs to change (new parameters, new description for UI, etc), you will need to deploy the change to each scheduler node and restart each one.

How can I deploy job changes without redeploying or restarting Tomcat?

Apart from using the Job Forking support noted above, if you want truly dynamic job changes that even support configuration additions/removals, the best approach we can offer for this is to use our embedded Scripting support.

You can either use something like the included GroovyJob, or write your own job that executes a job script on the file system. The latter approach lets you just replace script files on demand. If you use this approach, you can define a Java job which accepts a defined script name parameter, which you can then execute using Groovy, or one of our other supported scripting languages.

What level of scheduling precision does Obsidian support?

Obsidian supports minute-level scheduling precision. Obsidian values a balanced load-sharing algorithm over second-level precision.

What about Daylight Savings Time (DST) or Summer Time? Will Obsidian handle these gracefully?

We recommend against using DST time zones on scheduling servers as you will perhaps experience undesired side effects. For example, if you have a job that you want to run every hour, when a spring DST change pushes the clock back an hour, Obsidian will not execute it again since the time has repeated and it is viewed as having already run. Or you have a job scheduled to run during a window that ends up not occuring because of an autumnal time forward adjustment. If DST is absolutely required, Obsidian does handle it gracefully but we recommend you contact us to discuss the full implications.

How do I change the time zone that Obsidian uses?

Obsidian uses the Java timezone, which can be specified using the Java system property user.timezone. For example, in Tomcat you can append -Duser.timezone=Europe/Sofia to JAVA_OPTS in your startup script (e.g. startup.sh).

Note: Changing your timezone in an existing Obsidian installation can result in undefined behaviour if it has been running recently. We suggest setting your timezone before database creation when possible.

As of Obsidian 4.2.0, Time Zone ID may be specified in Cron patterns themselves to request that Obsidian run the job's scheduled according to the time of the TimeZone specified regardless of the default TimeZone of the Obsidian cluster.

How do I upgrade from a previous version of Obsidian?

See our Upgrade page for details.

What does the acronym "XYZ" mean?

Here are definitions of some acronyms commonly used in Obsidian's documentation.

What is the default username and password?

Each Obsidian installation using native authentication (the default) starts with a single default user named admin with password changeme. You should change this after your first login. See User Management for how to change a user's password.