SVRCONNs and INDISP(SHARED) listeners

Colin Paice has been writing a number of blog posts that highlight issues you need to know about and avoid in your MQ environment. You can follow Colin’s writing over on his blog, and also on the MQDev blog. Recently he wrote a short post on that “well known SVRCONN shared listener problem in a QSG” highlighting that not all MQ users realise it is something to be avoided.

I thought this topic could do with a fuller explanation – after all, sometimes understanding the reason behind something helps it stick in your mind better why not to do it.


Goals when connecting clients into a Queue Sharing Group

When you have client connected applications that are going to connect into a Queue Sharing Group (QSG) you have two main goals:-

  • Be able to connect to any member
    A QSG is all about availability, so you want to ensure that your clients always have somewhere to connect to. Unless something drastic happens, a QSG should always have at least one member queue manager running at all times, and your clients need to be able to find their way there.
  • Put/Get messages to/from Shared queues
    Your client applications want to be able to make use of the resources in a QSG, the shared queues – this gives the overall application (from client to backend) the best availability. Of course, it is also the case that clients connecting into the QSG can put to local queues, cloned local queues if you want it to work regardless of where the client application connected.

You can connect to any available QSG member with any kind of front-end routing (Sysplex Distributor; Big IP; CCDT; even a comma-separated CONNAME!) that points to the normal (non-shared) listener port.

Client into QSG

Clients connecting into QSG can use the non-shared listener port

What’s the difference between private and shared SVRCONN channels?

To understand the difference for SVRCONN, it pays to first understand the difference for MCA channels. In a QSG there are two different ways channels can run – referred to as the disposition of the channel, this can either be SHARED or PRIVATE.

  • A CHLDISP(SHARED) Channel
    • Outbound Channel
      An outbound channel, e.g. a SENDER, that is running as a shared channel is one that reads messages from a QSGDISP(SHARED) transmission queue. If you try to tell a sender channel to run shared and it’s transmission queue is not stored in the Coupling Facility (CF) it won’t let you.
    • Inbound Channel
      An inbound channel, e.g. a RCVR, that is running as a shared channel is one that connected itself to the queue manager through the shared/group listener port – that is the listener which has been started as INDISP(GROUP). This is the exact and only definition of an inbound CHLDISP(SHARED) channel.

    When running as a CHLDISP(SHARED) channel the other thing that is important to understand is the storage of state. Channel status is stored both locally in the in-memory channel status table, and also in the shared DB2 status table. This means that commands like DISPLAY CHSTATUS can be issued anywhere in the QSG and status about the channel can be displayed.

    Committed status, that is the details about the last batch of messages sent/received is stored on the SYSTEM.QSG.CHANNEL.SYNCQ (which is a QSGDISP(SHARED) queue) instead of the SYSTEM.CHANNEL.SYNCQ. This means that when a shared channel ends in-doubt, and is restarted on a different member of the QSG, the batch can be resolved and messaging can continue.

  • A CHLDISP(PRIVATE) Channel
    • Outbound Channel
      An outbound channel, e.g. a SENDER, that is running as a private channel is one that reads messages from a QSGDISP(PRIVATE) transmission queue. If you try to tell a sender channel to run private and it’s transmission queue is not stored on a Page Set it won’t let you.
    • Inbound Channel
      An inbound channel, e.g. a RCVR, that is running as a private channel is one that connected itself to the queue manager through the normal queue manager listener port – that is the listener which has been started as INDISP(QMGR). This is the exact and only definition of an inbound CHLDISP(PRIVATE) channel.

    When running as a CHLDISP(PRIVATE) channel the other thing that is important to understand is the storage of state. Channel status is only stored in the local in-memory channel status table. This means that to obtain information about channel status you must use the CMDSCOPE(*) construct and ask every queue manager about it’s channels.

    Committed status, that is the details about the last batch of messages sent/received is stored on the SYSTEM.CHANNEL.SYNCQ. This means that only the same queue manager can resolve an in-doubt batch for messaging to continue.

All of the above describes the messaging channels that go between two queue managers. It doesn’t say anything about CLNTCONN-SVRCONN channels.

The same rules still apply to SVRCONN channels in so much as they are applicable. First off a SVRCONN is an inbound channel, so we’re only interested in the inbound set of rules. Secondly, a SVRCONN channel has no committed status because it doesn’t move batches of messages in the way MCA channels do. So all we’re left with is the status used by DISPLAY CHSTATUS. So here’s the difference between a SVRCONN that is either SHARED or PRIVATE.

  • A CHLDISP(SHARED) Channel
    A SVRCONN that is running as a shared channel is one that connected itself to the queue manager through the shared/group listener port – that is the listener which has been started as INDISP(GROUP). When running as a CHLDISP(SHARED) channel the thing that is important to understand is the storage of state. Channel status is stored both locally in the in-memory channel status table, and also in the shared DB2 status table. This means that commands like DISPLAY CHSTATUS can be issued anywhere in the QSG and status about the channel can be displayed.
  • A CHLDISP(PRIVATE) Channel
    A SVRCONN that is running as a private channel is one that connected itself to the queue manager through the normal queue manager listener port – that is the listener which has been started as INDISP(QMGR). When running as a CHLDISP(PRIVATE) channel the thing that is important to understand is the storage of state. Channel status is only stored in the local in-memory channel status table. This means that to obtain information about channel status you must use the CMDSCOPE(*) construct and ask every queue manager about it’s channels.

So the difference is whether you have to issue this command (works for CHLDISP(SHARED)) which is answered by a single queue manager:-

DISPLAY CHSTATUS(MQGEM.SVRCONN) CHLDISP(SHARED) SHORT

Or this command (works for CHLDISP(PRIVATE)) which is answered by every queue manager in the QSG:-

DISPLAY CHSTATUS(MQGEM.SVRCONN) CHLDISP(PRIVATE) CMNDSCOPE(*)

to find out where your SVRCONN is actually running.

In order to have this slight difference in DISPLAY CHSTATUS command, you pay a cost, and that cost is the expense of updating the DB2 table with the information about the current owner of this channel. For a short lived SVRCONN channel, this cost can be a major proportion of it’s overall cost.

Summary

There is no difference that affects your goals when connecting clients to a QSG, but there is a cost. This is why Knowledge Center now carries the following advice:

Configuring SVRCONN channels for a queue-sharing group
The optimal configuration for SVRCONN channels in a queue sharing group is to set up private listeners in each CHINIT which use a different port number from the point to point channels. These listener ports are then used as the ‘back-end’ resources for a new workload distribution mechanism such as Sysplex Distributor using Virtual IP addresses (VIPA). The external VIPA address is then used as the target address for the CLNTCONN definitions in the network. The SVRCONN channel can be defined with QSGDISP(GROUP) so the same definition is available to all queue managers in the QSG. This configuration avoids using a shared listener, and therefore the reduces performance effect of the QSG maintaining shared channel state which is not needed for client/server channels.


IBM Certified SpecialistIBM Champion 2016 Middleware

Morag Hughson
IBM Champion 2016 – Middleware
IBM Certified System Administrator – MQ V8.0
Find her on: LinkedIn: http://uk.linkedin.com/in/moraghughson Twitter: https://twitter.com/MoragHughson SlideShare: http://www.slideshare.net/moraghughson developerWorks: https://www.ibm.com/developerworks/community/profiles/html/profileView.do?userid=110000EQPN

Advertisements

The team at MQGem would love to hear what you think. Leave your comments here.

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s