Job Pinning Example Flow Chart
This job pinning example shows how Unix jobs run only on Unix computers and how Windows jobs run only on Windows computers.
In general, this example shows how certain jobs can be forced to run on certain computers -- or how certain computers can refuse to run certain jobs.
To run this example, you need to start two Flux job scheduler engines. The first job scheduler engine represents the Unix computer (even though your computer may not actually be a Unix computer). The second job scheduler engine represents the Windows computer (even though your computer may not actually be a Windows computer).
NOTE: This example REQUIRES that you have a database working with Flux. In order to run this example you will also need to configure the properties files as well as the engines' classpaths to point to the database you are using. For information on getting Flux running with a database, view the appropriate sections within the End User's Manual. If you already have a database running with Flux, view the "Configuring this Example to use a Database" section below.
Configuring this Example to use a Database
First, if you have not previously done so, add all the necessary JAR files you will need to run your database with Flux into the lib directory, located under your Flux installation directory. Once you have added the appropriate JAR files, add references to these files within the run-unix-server and run-windows-server scripts in the directory that this example is located in. These references should look similar to the following: ..\..\..\lib\<jar name>.jar; for Windows users or ../../../lib/<jar name>.jar: for Unix users.
Once your database specific jar files have been added, open the unix-fluxconfig.properties and windows-fluxconfig.properties files. You must specify the appropriate database properties in the appropriate configuration options within these files. The options will be marked with a tag similar to the following: < -- EDIT: -- >.
Once you have completed the previous steps, your database will be configured to run with Flux and you will be ready to move on to the next part of this example.
Running the Job Pinning Example
Open a command prompt or shell, then execute the run-windows-server script. This command starts the Windows server in a cluster, using your database to store the clustered job data.
Now open a second command prompt or shell, then execute the run-unix-server script. This command starts the Unix server in the same cluster.
After executing both scripts, start the Flux Designer by running the flux-designer script from the Flux installation directory.
Create a flow chart named /unix/unix job with a single Console Action. Set the Console Action's Message property to Unix.
Create a second job named /windows/win job with a single Console Action. Set the Console Action's Message property to Windows.
Now export the Unix job to the Windows job scheduler engine. Similarly, export the Windows job to the Unix job scheduler engine.
Switch back to the command prompts where your Windows and Unix servers are running.
Notice how the Windows server ran the Windows job, even though that Windows job was originally exported to the Unix server. Likewise, the Unix server ran the Unix job, even though the Unix job was originally exported to the Windows server.
This behavior demonstrates job pinning. Windows jobs are pinned to Windows machines, and Unix jobs are pinned to Unix machines. Of course, you can generalize job pinning to suit your particular needs.