This is part of a series of small blog posts which will cover some of the smaller, perhaps less likely to be noticed, features of IBM MQ. Read other posts in this series.

I talked about channel batches in the first Little Gem blog post (IBM MQ Little Gem #1: XBATCHSZ) and about how to work out what your achieved batch sizes are. In this post I'll look at another aspect of channel batches - the factors that result in a batch being closed.

Batch Closure

What does it mean for a batch to be closed? When a channel transfers messages across the network to a partner queue manager, it does so a number at a time. It does it this way for efficiency reasons, not spending the extra cost to confirm each message individually but instead confirming that the partner received a few messages at a time. The set of messages sent and then confirmed is known as a batch of messages.

The channel needs to decide how many messages to send in one batch. This can be quite a difficult decision since messages don't turn always turn up regularly like clockwork, sometimes they dribble in here and there. So there are a few factors to determine when a channel will decide that it has enough messages in the batch and thus proceed to close the batch and confirm that the partner queue manager received the batch of messages.

Closure Factors

Some IBM MQ users reading this will be familiar with a few of the well known factors. The first is a full batch; a channel has an attribute BATCHSZ which determines the maximum number of messages in a batch, and is set to 50 by default. When a channel has sent a full batch of messages, regardless of whether there are still more messages on the transmission queue, it will close the batch and confirm receipt of the batch with the partner queue manager, before sending any more messages.

Another well known factor is the empty transmission queue state; a channel may have sent a partial batch so far and then discover there is an empty transmission queue, i.e. there are no more messages ready to be sent over this channel right now. This state will cause the channel to close the batch. You can delay this closure by using the BATCHINT attribute to tell the channel to wait a little while in case some more messages turn up before closing the batch.

Setting your maximum batch size

The default BATCHSZ is set to 50, and this is a good number for most channels. The reason this is a good number is that you want to send a high enough number of messages so that the cost of the confirmation at the end of the batch is spread between a number of messages and so is a relatively small cost per message, but you don't want to send too many messages that the number of bytes that have to be retransmitted is too many, should the network fail mid batch.

The default of 50 is probably fine unless you have a really rubbish network that keeps dropping, or you have really large messages. In both of those cases you'd probably lower your BATCHSZ so less retransmitting of message data happens.

Where it can become difficult to set your BATCHSZ is when you have a mixture of message sizes.

Measuring your batch in bytes

If all your messages were 4K in size and you sent up to 50 in a batch, then you're looking at a maximum 200K to be retransmitted if the network drops before the batch is completed. A couple of 100K messages could total that same number of bytes in only two messages, and you've still another 48 messages to go in the batch. Clearly when a channel is moving a mixture of message sizes, the BATCHSZ attribute is not as useful for measuring the size of the batch.

There is another channel attribute that works alongside BATCHSZ that is sometimes forgotten about and that is BATCHLIM. BATCHLIM is essentially BATCHSZ but measured in bytes instead of number of messages. Looking at our above example, if you set BATCHSZ to 50, and BATCHLIM to 250K, and then send three 100K messages, the channel would consider the batch full (of bytes) and close it. If you then send fifty 4K messages, the channel would consider the next batch full (of messages) and close it.

So, as you can see that setting BATCHSZ for your smaller or average size of messages with BATCHLIM to catch the cases where you have to send a lot of bytes work very well in combination.

You may very well already be benefitting from BATCHLIM, which was added to the WebSphere MQ product in V7.1, because the default was set intelligently. The default value for BATCHLIM is 5000K, which is enough for 50 x 100K messages, and 50 is the default BATCHSZ. If your messages are larger than 100K, then BATCHLIM will by default be closing your batches sooner than it did prior to V7.1, which is a good thing since risking a retransmission of such a large number of bytes is best avoided.

To set BATCHLIM, you set the number of Kilobytes, so for 5000K you set BATCHLIM(5000).

So now you know, BATCHLIM is there, working hand in hand with BATCHSZ, protecting your batches from becoming too large. If you have an extremely reliable network you may consider increasing it, but just remember about the retransmission risk and delay in persistent message availability if you do.