Job Forking

As of Obsidian 3.0.0, Obsidian can run each job in its own JVM. This allows for a number of possibilities, not the least of which is supporting dynamic changes to your deployed, compiled jobs, also known as hot-swapping of JARs. In theory, you could even specialize classpaths on a per job basis by customizing the executions scripts provided.

To ensure backwards compatibility and controlled usage of this functionality, it is disabled by default for the cluster. Standalone deployments are configured to have it enabled, but are not active until you enable it for the cluster.

Configuring Job Forking

Enabling Job Forking - Cluster

First you must enable the functionality on the cluster. This is a System Parameter found in the JobSpawner category. You may enable it via the Admin UI, via one of the provided APIs (Embedded API or REST API) or the Initializing and Restoring support.

Enabling Job Forking - Node

Once you've done that, you'll need to enable it on each desired node. Standalone Schedulers are already thus enabled. For other nodes, you will need to set the appropriate properties value entry.

com.carfey.obsidian.jvmJobForkingEnabledOnThisNode=true

In a Standalone Scheduler, Job Forking will be functional on next start/restart.

Script Location

You may wish to specify the forking script location for other deployments ( Embedded, Scheduler with Admin WebApp, or for other reasons.

com.carfey.obsidian.forkedJobScriptLocation=/Obsidian-3.0.0 This property is the location of the fork scripts. Obsidian is bundled with obsidianForkedJob.bat and obsidianForkedJob.sh. These are the expected script names. If you wish to customize these scripts or use your own, you are free to do so. Details about the #Forked Obsidian Job Runner will be helpful in your customization efforts.

Classpath Override

com.carfey.obsidian.forkedJobscriptClasspathOverride=/home/user/workspace/obsidian/bin:/home/user/workspace/obsidian/lib/activation-1.1.jar:/home/user/workspace/obsidian/lib/mail-1.4.jar:/home/user/workspace/obsidian/lib/dom4j-1.6.1.jar:/home/user/workspace/obsidian/lib/obsidian.jar:/home/user/workspace/obsidian/lib/log4j-1.2.9.jar:/home/user/workspace/obsidian/lib/gson-2.2.2.jar:/home/user/workspace/obsidian/lib/bsh-2.0b4.jar:/home/user/workspace/obsidian/lib/groovy-all-2.1.8.jar:/home/user/workspace/obsidian/lib/jython-standalone-2.5.3.jar:/home/user/workspace/obsidian/lib/mariadb-java-client-1.1.5.jar This allows you to override the default classpath that is used by the forked execution instance. The sample demonstrates usage in an embedded Obsidian instance running inside an Eclipse project. The default classpath is built automatically by the script and it assumes a Standalone Scheduler deployment. As such, it uses the jars in the standalone/ directory for building the classpath. If you require custom classpath on a per job basis, modification of the script(s) will be required.

What is Job Forking Doing?

Job Forking is implemented by calling a script

Forked Obsidian Job Runner

Use the following optional property if you need to override the default classpath that is built using the contents of the standalone directory. This allows for job forking support in embedded and even webapp deployments. Use the classpath format supported by your operating system.