The JSR-352 implementation in WebSphere Liberty includes the ability to publish messages into a topic tree at interesting points in the lifecycle of a job.  Messages (or events) are published around the start and end of a job, as well as the start and end of each step.  Most interesting to us is the event published at each checkpoint.  In our baseline job there will be 10,000 checkpoints and thus 10,000 messages published.  Does enabling this feature (which allows a monitor to track the status of the job) significantly slow down execution of the job itself?  Let’s find out.

We can configure the server to publish batch event messages by pointing it to a messaging engine.  We can use the WAS messaging server built into Liberty or point to an instance of MQ running on our z/OS system.  If we use MQ we can connect over TCP/IP or cross-memory (Client or Bindings mode).

For my experiment I choose to run using the built in Liberty messaging services located in the same server running the batch job.  I thought that would probably interfere the most with the running job and be slower (going through TCP/IP) than a Bindings mode connection to MQ. 

Remember that we’re comparing to our baseline run with no ItemProcessor, handling 10 million records, checkpointing every 1000 items.  That step ran in about 4 minutes and 32 seconds.  For our test I ran the exact same configuration except that the server was publishing messages as the job progressed.  This time the job took 4 minutes and 42 seconds.