Skip to main content

Websphere MQ Clustering - Middleware News

Clustering
Main purpose : workload balancing.
    Distributed queing is when you group queue managers in a cluster : the queue managers can make the queues that they host available to every other queue manager in the cluster. Any queue manager can send a message to any other queue manager in the same cluster without explicit channel definitions, remote-queue definitions, or transmission queues for each destination. Every queue manager in a cluster has a single transmission queue from which it can transmit messages to any other queue manager in the cluster.
    Each queue manager in a cluster needs to define only:
    • one cluster-receiver channel on which to receive messages
    • one cluster-sender channel with which it introduces itself and learns about the cluster
    • which own queues it wants to make available to the cluster
    As with distributed queuing, an application uses the MQPUT() call to put a message on a cluster queue at any queue manager. An application uses the MQGET() call to retrieve messages from a cluster queue on the local queue manager.
    You can only GET from a local cluster queue, but you can PUT to any queue in a cluster. If you open a queue to use the MQGET command, the queue manager will only use the local queue.
    Each queue manager has a definition for the receiving end of a channel called TO.qmgr on which it can receive messages. This is a cluster-receiver channel. A cluster-receiver channel is similar to a receiver channel used in distributed queuing, but in addition to carrying messages this channel can also carry information about the cluster.
    Each queue manager also has a definition for the sending end of a channel, which connects to the cluster-receiver channel of one of the Full Repository (FR) queue managers. This is a cluster-sender channel. A cluster-sender channel is similar to a sender channel used in distributed queuing, but in addition to carrying messages this channel can also carry information about the cluster.
    Once both the cluster-receiver end and the cluster-sender end of a channel have been defined, the channel starts automatically.
    In any cluster you need to nominate two queue managers to hold full repositories.
    The clusters use the publish/subscribe model for internal messaging (and will Subscribe to only 2 FR)
    Queue Manager Repository is kept in SYSTEM.CLUSTER.REPOSITORY.QUEUE queue
    Cluster information is carried to repositories (whether full or partial) on a local queue called SYSTEM.CLUSTER.COMMAND.QUEUE.
    Few Q&A ;
    • how many FR ? 2
    • DISCINT=0 ? no
    • 2 qmgrs just to be FR ? yes, on a separate server
    Good intro : Getting started with queue manager clusters.
    Interesting summary :
    #1 Regardless of how many FRs you have, each FR should have a manual CLUSSNDR defined to every other FR.
    #2 If every FR has a CLUSSNDR to every other FR, each FR will know about every cluster attribute on every QM in the cluster.
    #3 A PR will only ever publish info to 2 FRs. A PR will only ever subscribe to 2 FRs. Period. It doesn't matter how many manual CLUSSNDRs you define on that PR. A PR will only ever send its info (publish) to 2 FRs and will only get updates (subscribe) from 2 FRs.
    #4 You should only define one CLUSSNDR to one FR from a PR.
    #5 If 2 FRs go down in your cluster, your cluster will be able to send messages just fine. But any changes to cluster definitions become a problem. Any PRs that used both of these down FRs will still function for messaging, but they will not be made aware of any changes in the cluster because both of it's FRs are N/A.
    #6 If two of your FRs are down, and you still have other FRs, you could go to your PRs and delete the CLUSSNDR to the down FR, define a CLUSSNDR to an available FR and issue REFRESH CLUSTER(*) REPOS(YES). This would cause your PR to register with an available FR and thus pick up cluster changes.
    #7 In a properly designed system the liklihood of 2 FRs being down is next to zero, so the need for more than 2 FRs is next to zero. And even if both FRs are down it doesn't mean your cluster will come to a screeching halt.
    Just use 2 FRs.
    Problem : stuck message(s) @ Xmit Q(s)!

    Comments

    adsrerrapop

    Popular posts from this blog

    IBM Websphere MQ interview Questions Part 5

    MQ Series: - It is an IBM web sphere product which is evolved in 1990’s. MQ series does transportation from one point to other. It is an EAI tool (Middle ware) VERSIONS:-5.0, 5.1, 5.3, 6.0, 7.0(new version). The currently using version is 6.2 Note: – MQ series supports more than 35+ operating systems. It is platform Independent. For every OS we have different MQ series software’s. But the functionality of MQ series Default path for installing MQ series is:- C: programfiles\BM\clipse\SDK30 C: programfiles\IBM\WebsphereMQ After installation it will create a group and user. Some middleware technologies are Tibco, SAP XI. MQ series deals with two things, they are OBJECTS, SERVICES. In OBJECTS we have • QUEUES • CHANNELS • PROCESS • AUTHENTICATION • QUERY MANAGER. In SERVICES we have LISTENERS. Objects: – objects are used to handle the transactions with the help of services. QUEUE MANAGER maintains all the objects and services. QUEUE: – it is a database structure

    IBM Websphere MQ Reason code list / mq reason codes / websphere mq error codes / mq error messages

    Reason code list ================= The following is a list of reason codes, in numeric order, providing detailed information to help you understand them, including: * An explanation of the circumstances that have caused the code to be raised * The associated completion code * Suggested programmer actions in response to the code * 0 (0000) (RC0): MQRC_NONE * 900 (0384) (RC900): MQRC_APPL_FIRST * 999 (03E7) (RC999): MQRC_APPL_LAST * 2001 (07D1) (RC2001): MQRC_ALIAS_BASE_Q_TYPE_ERROR * 2002 (07D2) (RC2002): MQRC_ALREADY_CONNECTED * 2003 (07D3) (RC2003): MQRC_BACKED_OUT * 2004 (07D4) (RC2004): MQRC_BUFFER_ERROR * 2005 (07D5) (RC2005): MQRC_BUFFER_LENGTH_ERROR * 2006 (07D6) (RC2006): MQRC_CHAR_ATTR_LENGTH_ERROR * 2007 (07D7) (RC2007): MQRC_CHAR_ATTRS_ERROR * 2008 (07D8) (RC2008): MQRC_CHAR_ATTRS_TOO_SHORT * 2009 (07D9) (RC2009): MQRC_CONNECTION_BROKEN * 2010 (07DA) (RC2010): MQRC_DATA_LENGTH_ERROR * 2011 (07DB) (RC2011): MQRC_DYNAMIC_Q_NAME_ERROR * 2012 (07DC) (RC201

    IBM WebSphere MQ – Common install/uninstall issues for MQ Version on Windows - Middleware News

    Creating a log file when you install or uninstall WebSphere MQ WebSphere MQ for Windows is installed using the Microsoft Installer (MSI). If you install the MQ server or client through launchpad , MQPARMS or setup.exe , then a log file is automatically generated in %temp% during installation. Alternatively you can supply parameters on the installation MSI command msiexec to generate a log file, or enable MSI logging system-wide (which generates MSI logs for all install and uninstall operations). If you uninstall through the Windows Add/Remove programs option, no log file is generated. You should either uninstall from the MSI command line and supply parameters to generate a log file, or enable MSI logging system-wide (which generates MSI logs for all install and uninstall operations). For details on how to enable MSI logging, see the following article in the WebSphere MQ product documentation: Advanced installation using msiexec For details on how to enable system-w