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.
If you are monitoring a job that has a partitioned step, things are going to get pretty exciting. Once the started message is published for the step, the process of spinning off the partitions will begin.
Each partition will publish its own message to the
started topic under step partitions. You might know how many partitions to expect for a given job if the partitioning is hard-coded in the JSL (or done programmatically into a fixed number of partitions with varying work for each partition). But nothing says that all the partitions start at once. The application can limit the number of partitions that can run concurrently, and, of course, availability of threads and processor resources to run them can restrict concurrency.
As the partitions run, they may publish messages for checkpoints as they take them. But once all the fun is over, each partition will publish a message indicating how it finished.
As usual, when things work well a message is published into the partition
completed topic. Of course, that doesn’t necessarily mean everything worked as you’d hoped, just that no exceptions were thrown out of the partition. Check the exit status in the message content to see what the application actually thought about how things went.
If an exception does get thrown out of the partition and not handled through skip or retry processing, then the partition failed, and a message will be published to the partition
As with the step messages, if the job is stopped while a partition is running then the partitions noticing the change in status will publish a message to the
stopped topic for partitions.
That’s all there is for partitioned step events. For jobs where the partitioning is at least somewhat predictable it should enable a monitor to display progress and status of the various partitions.