Channel compression in IBM MQ classes for Java

Compressing the data that flows on a channel can improve the performance of the channel and reduce network traffic. IBM MQ classes for Java use the compression function built into IBM MQ.

Use function supplied with IBM MQ, we can compress the data that flows on message channels and MQI channels and, on either type of channel, we can compress header data and message data independently of each other. By default, no data is compressed on a channel. For a full description of channel compression, including how it is implemented in IBM MQ, see Data compression (COMPMSG) and Header compression (COMPHDR).

An IBM MQ classes for Java application specifies the techniques that can be used for compressing header or message data on a client connection by creating a java.util.Collection object. Each compression technique is an Integer object in the collection, and the order in which the application adds the compression techniques to the collection is the order in which the compression techniques are negotiated with the queue manager when the client connection starts. The application can then assign the collection to the hdrCompList field, for header data, or the msgCompList field, for message data, in the MQEnvironment class. When the application is ready, it can start the client connection by creating an MQQueueManager object.

The following code fragments illustrate the approach described. The first code fragment shows you how to implement header data compression:

Collection headerComp = new Vector();
headerComp.add(new Integer(CMQXC.MQCOMPRESS_SYSTEM));
:
MQEnvironment.hdrCompList = headerComp;
:
MQQueueManager qMgr = new MQQueueManager(QM);

The second code fragment shows you how to implement message data compression:

Collection msgComp = new Vector();
msgComp.add(new Integer(CMQXC.MQCOMPRESS_RLE));
msgComp.add(new Integer(CMQXC.MQCOMPRESS_ZLIBHIGH));
:
MQEnvironment.msgCompList = msgComp;
:
MQQueueManager qMgr = new MQQueueManager(QM);

In the second example, the compression techniques are negotiated in the order RLE, then ZLIBHIGH, when the client connection starts. The compression technique that is selected cannot be changed during the lifetime of the MQQueueManager object.

The compression techniques for header and message data that are supported by both the client and the queue manager on a client connection are passed to a channel exit as collections in the hdrCompList and msgCompList fields of an MQChannelDefinition object. The actual techniques that are currently being used for compressing header and message data on a client connection are passed to a channel exit in the CurHdrCompression and CurMsgCompression fields of an MQChannelExit object.

If compression is used on a client connection, the data is compressed before any channel send exits are processed and extracted after any channel receive exits are processed. The data passed to send and receive exits is therefore in a compressed state.

For more information about specifying compression techniques, and about which compression techniques are available, see Class com.ibm.mq.MQEnvironment and Interface com.ibm.mq.MQC.

Parent topic: Writing IBM MQ classes for Java applications