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.
Assume we’ve configured a Liberty server as a batch dispatcher. We also have a batch message queue defined in MQ. Finally, we’ve got two servers configured as executors, both defined to select messages for our one batch application. We submit a job to the dispatcher, which causes a message to be placed on the queue. Which server runs the job?
You can’t tell which one will get it. It just depends on which one MQ delivers the message to. Ok, fair enough. Suppose you submit two jobs at basically the same time. Will one job go to each server or will one of the servers get both? Again, it depends how MQ handles message delivery to the activation specifications. Well. Fine. Suppose I submit thousands of jobs in a burst. What happens then? Ah…that we know.
Nothing good. MQ will start delivering the messages to the servers the servers will start spinning up threads to run the jobs. If the jobs aren’t really short, more and more messages will arrive while the first jobs are still running. More threads will get created. Eventually one (or both) servers will just be overwhelmed with threads and running jobs and bad things will happen.
Can we prevent this? Sure! Part of the configuration of an activation specification is the ability to set a limit on the number of messages that are being processed by the server at one time. This brings up an interesting point – while the job is running, the message is “being processed”. The server isn’t done with the message until the job finishes. Which allows us to solve our overrun server problem.
By setting a limit on the number of messages being processed at once, we can limit the number of jobs (for that activation specification) being run in the server at once. Careful selection of this value will allow the server run however many jobs it is able to run, but not more than that.
The configuration used to set this limit is slightly different if you are using the integrated messaging provider that comes with Liberty or if you are using IBM MQ. You can see IBM Techdocs paper WP102600 for examples of both.