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.
Last time we talked about the ability of the Liberty JSR-352 support to publish messages (events) into a topic tree at certain points in the lifecycle of a batch job. This week we’ll take a look at what events are available relating to a job instance.
Before we get to that, let’s remind ourselves what a job instance actually is (as compared to a job execution). It all has to do with restarting failed or stopped jobs. When you submit a job, you create a job instance. When the job starts running, that’s a job execution under that job instance. If the execution fails and you want to restart the job, you get a new execution under that same instance. Contrast that to just submitting the job again which creates a whole new instance (and execution).
Got it? Great! Since we are talking about submitting jobs and creating instances, this would be a good point to talk about the events relating to that. Any time a new job gets submitted a message will be published into the
batch/jobs/instance/submitted topic. As we mentioned last time, that’s the relative location in the topic tree based off wherever the batch topic root is configured to go.
Alright, so that one event would allow you to create a monitor that was notified anytime a new job is submitted. What other events get published? Well, when the job starts running you’ll get a message in the
dispatched topic (under
batch/jobs/instance also, as are all the topics we’ll talk about today). Knowing when dispatch starts merged with the submit allows a monitor to know what is waiting to execute (and the message content tells you what those jobs are).
As jobs finish messages are published into one of several topics:
failed. All of those indicate the job ended, but the specific topic the message shows up under tells you how. Note that a stopped job will have posted a message to the
stopping topic when the stop was issued.
Again, all this allows a monitor to know what jobs are running and what the state of completed jobs is, as well as identify jobs that have been stopped but haven’t yet actually ended. Of course, you can get all this information from the Admin Center or by using the REST interface to query the state of things. Being notified about events allows a monitor to just sit back and observe without having to actively poll. And a monitor could then generate its own alerts based on whatever criteria makes sense.
Ok, there are three more job instance related events. Two of them have to do with multi-server configurations that we haven’t talked about yet:
jms_consumed. Messages are published in these topics when jobs are queued or taken from the queue in a multi-server configuration.
The final job instance event is purge. A message is published there when a purge operation has cleaned up the job from the Job Repository. If you are managing an archive of job logs somewhere, you might trigger off a job-purge message to move the job log from a local archive to a tape library (or get rid of it entirely).