This post is part of a series delving into the details of the JSR-352 (Java Batch) specification. Each post examines a very specific part of the specification and looks at how it works and how you might use it in a real batch application.To start at the beginning, follow the link to the first post.
The next post in the series is here
.This series is also available as a podcast on iTunes, Google Play, Stitcher, or use the link to the RSS feed.
We’ve talked about the multi-server configuration for Liberty that allows jobs to be placed on a message queue and processed by Liberty servers acting as job executors. And so far, we’ve just assumed that those messages are processed in the order they are put on the queue. Well, they are, but that’s only because we haven’t done anything special to change it.
By default all the messages representing jobs are put on the queue with the same priority. That means they get processed in the order they are received. But JMS supports a message priority. If you could specify a different priority for the message representing the job, you could influence the order in which the jobs (messages) are processed.
By default the message priority is set to four. The allowed range is zero to nine, where zero is the lowest priority and nine is the highest (that will be hard to remember because it makes sense..). When a JMS application puts a message on a queue, it can specify a message priority. But in this case, the batch container code in Liberty is the JMS application, so how do you get it to specify the priority you want? By using a special, magical, job parameter. Remember that when you use
batchManagerZos (or the REST interface directly) to submit a job you can specify job parameters as name/value pairs. The magic parameter name for job priority is
If you set that job parameter to a numeric value (like 9) then the message, and thus your job, will be assigned that priority. A job (or message) with a priority of 9 will jump ahead of all the other jobs on the queue with lower priority. Of course jobs with the same priority are processed in the order they are received so a priority of 9 may put your job in line behind all the other priority 9 jobs..
By default a restarted job uses the same job parameters as the original job, unless you override them. That means a restarted job will have the same priority as the original job, unless you deliberately change it.
But wait, there’s more! What if you want your job to wait to run until later? You want to submit it now, but delay it actually running until midnight or some other time. Turns out there’s JMS support for that too. When a message is put on a queue you can specify a delay (conveniently in milliseconds) until the message should be delivered. And Liberty conveniently surfaces that ability as another special, magical, job parameter called
com_ibm_ws_batch_message_deliveryDelay. Just get out your calculator and figure out how many milliseconds are between now and midnight (more or less) and there you go.
Unlike message priority, a delay value is not carried forward to a restart of the job. That would be confusing.
One last caution.. if you are using IBM MQ as the messaging engine an extra system queue has to be defined to give MQ somewhere to put the message while it is delayed. See the WebSphere Knowledge Center for details.
So if your job is urgent (or not) you can make it run sooner (or later).