MQI client: Default behavior of client-connection and server-connection channels

In Version 7.0 the default settings for client and server connection channels changed to use shared conversations. This change affects the behavior of heartbeats and channels exits, and can have an impact on performance. Before Version 7.0, each conversation was allocated to a different channel instance. From Version 7.0, the default for client and server connections is to share an MQI channel. We use the SHARECNV (sharing conversations) parameter to specify the maximum number of conversations that can be shared over a particular TCP/IP client channel instance. The possible values are as follows:

SHARECNV(0)

This value specifies no sharing of conversations over a TCP/IP socket. The channel instance behaves exactly as if it was a Version 6.0 server or client connection channel, and we do not get the extra features such as bi-directional heartbeats that are available when you set SHARECNV to 1 or greater. Only use a value of 0 if we have existing client applications that do not run correctly when you set SHARECNV to 1 or greater.

SHARECNV(1)

This value specifies no sharing of conversations over a TCP/IP socket. Performance on distributed servers is similar to that for a value of 0. Client heartbeating (whether in an MQGET call or not) and read ahead are available, and channel quiescing is more controllable. We can usually use this setting with existing Version 6.0 client applications.

SHARECNV(2) to SHARECNV(999999999)

Each of these values specifies the number of shared conversations. If the client-connection SHARECNV value does not match the server-connection SHARECNV value, then the lowest value is used. The default value is SHARECNV(10), which specifies 10 threads to run up to 10 client conversations per channel instance. However, on distributed servers there are performance issues with SHARECNV channels that can be eased by using SHARECNV(1) wherever possible.

For all SHARECNV values of 1 or greater, the channel supports the following features:

• Bi-directional heartbeats
• Administrator stop-quiesce
• Read-ahead
• Asynchronous-consume by client applications

We can also set the MQCONNX option, MQCNO_NO_CONV_SHARING and connect the application to a channel with SHARECNV set to a value greater than 1. The result is the same as connecting the application to a channel with SHARECNV set to 1.

Performance

The change in Version 7.0 to use shared conversations, and further enhancements introduced in Version 8.0, can impact performance on distributed servers. See Tuning client and server connection channels.

Heartbeats

From Version 7.0, heartbeats can flow across the channel at any time in either direction. The SHARECNV(0) and Version 6.0 behavior is for heartbeats to flow only when an MQGET call is waiting.

Channel exits

The behavior of a client or server connection channel exit changes when the channel is sharing conversations (that is, when you set SHARECNV to a value greater than 1). It is unlikely, but possible, that the change affects the behavior of existing exits. The change is as follows:

• Send or receive exits can alter the MQCD structure on an MQXR_INIT call. The effect of these exits differs, depending on whether the conversation is shared with other conversations on the same channel:
  • If the MQCXP SharingConversations field passed to the exit instance is set to FALSE, this exit instance is the first, or only, conversation on the channel instance. No other exit can be changing the MQCD at the same time, and changes that are made to the MQCD can affect the way that the channel runs.
  • If the MQCXP SharingConversations field passed to the exit instance is set to TRUE, this exit instance is a subsequent conversation. It is sharing the channel instance with other conversations. Changes made to the MQCD in the exit instance are retained in the MQCD but do not affect the way the channel runs.
• Send, receive, and security exit instances can alter the MQCD, when the MQCXP SharingConversations field is set to TRUE. Exit instances on other conversations might be changing the MQCD at the same time. Updates written by one exit instance can be overwritten by another instance. It might be necessary to serialize access to the MQCD across these different exit instances to maintain the consistency of fields in MQCD.

Updating MQCD when the SharingConversations field is set to TRUE does not affect the way the channel runs. Only alterations made when the MQCXP SharingConversations field is set to FALSE, on an MQXR_INIT call, change channel behavior.