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.
-----
Batch jobs write messages. Where do those messages go? In a traditional batch environment, there will be some sort of log produced by the job that you can look at to see how things are going, maybe debug a problem. What happens to those messages for a Java Batch job running inside Liberty?
Well, like any message written by an application running inside Liberty, they end up in the server output. But that’s not very helpful. More than one job can be running concurrently inside a server at the same time and their messages will get all mixed up together in the server log. It would be nice if each job had its own log somewhere.
And so they do. The Liberty Batch implementation creates a folder called joblogs in the server’s logs folder. A directory structure underneath that separates the output from jobs by application name, then by date of execution, and then by instance and execution identifiers.
At first, that seems like it would be enough. Each job execution then gets its own separate joblog file and they are managed in a folder hierarchy that makes it easy to find the one you want. But, of course, nothing is every as easy as it seems like it should be.
Remember that the JSR-352 specification supports concurrent execution models with a partitioned step and with a split/flow. When the application has multiple parts running concurrently, you don’t want them all writing into the same joblog file. That’s going to make a mess of things.
For that reason, more directories are created under the execution for a split and the flows within it and each one gets its own job log. Similarly, partitioned steps get separate log files for each partition.
Which means that while a nice simple “Hello, World!” batch job will have a nice simple job log file, for a complex job with nested Splits and partitioned steps you’ll have a pile of different log files for each thread of execution – in addition to the main log for the main thread of the job itself.
You can also ask the Liberty Batch implementation to break the log into parts if you want to keep the individual log files from getting too big (whatever “too big” means to you).
Next time we’ll look at fetching the joblog(s) using the REST interface.