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.
-----
There’s one more topic in the batch/jobs/instance topic tree that we haven’t talked about: jobLogPart. A message gets published to this topic whenever a job log part is completed. When does that happen?
Recall that the main thread of the job writes messages to a log file. You can configure that log to “fill up” after a number of messages (default is 1000) or after some time period has expired. When the log is “full” the file is closed and a new one created for messages from the job going forward. As part of closing the old file a message is published to the jobLogPart topic.
That message has the job instance and execution identifiers as properties. That enables a subscriber to filter on messages relating to a specific job. The content of the message is the job log contents itself.
Remember also that if the job has partitions or uses the split/flow construct then several threads may be executing for the job besides the main thread. Each of those threads writes into its own separate log file. When those logs are “full” or the thread ends (the partition or the flow) then the log file is closed and the content published to the jobLogPart topic.
If you have a central location where you want to keep all the logs from all the jobs, then rather than have some tooling use the REST interface to go harvest the job logs, you could establish a subscriber to the jobLogPart topic and be handed the job log contents as they fill or complete. A Message Driven Bean (MDB) might be ideal for this purpose.
If you’d like to feed your batch job logs to some log analysis service, subscribing to this topic would allow that service easy access to all the log contents.
Just remember that log parts messages are published in the order the log files fill or things complete. If you have four partitions running concurrently producing enough output to cause the log files to reach the configured maximum number of records, then messages will be produced for the four partitions as they fill and move to new files. The messages for one partition can interleave with messages from other partitions, so be careful.
Next time we’ll move in one layer and look at step-related events.