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.
Once again, suppose we have a dispatcher putting jobs on a message queue being handled by two executor servers. Suppose both servers have message selectors defined to process messages for an application called MyApp. And finally, suppose one executor’s selector adds that it only wants MyApp application names where a job parameter of JOBCLASS=A was specified, and the other executor’s selector only allows JOBCLASS=B.
Got that? So, if we submit a MyApp job with JOBCLASS=A it goes to the first server and if we submit a MyApp job with JOBCLASS=B it goes to the second server. Fabulous.
Now we submit a MyApp job and specify JOBCLASS=C. What happens? If it is a typo, it would be nice if the job just failed. But it might not be a typo. It might be that you do indeed have a server that processes JOBCLASS=C jobs for the MyApp application. But they are only active from midnight to four in the morning (and it isn’t in that window right now). In that case you’d like the job (the message representing it really) to just hang out in the queue until midnight when automation starts the server for JOBCLASS=C and then run the job.
And that’s what happens. If no server can be found that has a message selector string that will match the properties on a message, that message will just wait in the queue until something turns up.
In cases where the mismatch is intentional, that’s awesome. It allows you to submit jobs to run in servers that aren’t presently active, and the jobs will just wait around in the queue until the server gets started to handle them.
Or you could do something really cool. When the job is submitted and put on the queue batch event messages are published into the batch topic tree. A monitor could subscribe to those topics and, being aware of what servers are up and what properties they handle, could recognize a job that didn’t match the current set of servers and (on demand) start up the appropriate server needed to handle the job.
Such a monitor would also be handy in case the mismatch really is a typo. If you submit a job with JOBCLASS=1 (where all job classes are letters) that job is just going to sit in the queue forever. A clever enough monitor might recognize that as a problem and generate an alert.