Skip to Main Content

This is an IBM Automation portal for Integration products. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (

Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,

Post your ideas
  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.

Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal ( - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal ( - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM. - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

Status Not under consideration
Created by Guest
Created on Jun 12, 2012

Workload Balance at Queue level for multiple Subscriptions

RFE is for having the Workload balancing at queue level when we have multiple sucscriptions . Please refer the PMR 82575,442,000 for more details.

Idea priority Medium
RFE ID 23391
RFE Product IBM MQ
  • Guest
    Jan 7, 2022

    We recognise that this is a valid requirement. However it doesn't fit with our delivery plans for the next couple of years.

    As a result we are declining this Idea. While declined the Idea can still be voted, and commented, upon.

  • Guest
    Oct 15, 2015

    Due to processing by IBM, this request was reassigned to have the following updated attributes:
    Brand - WebSphere
    Product family - Integration
    Product - IBM MQ

    For recording keeping, the previous attributes were:
    Brand - WebSphere
    Product family - Connectivity and Integration
    Product - IBM MQ

  • Guest
    Jun 17, 2013

    This is a key requirement for our company. We have implemented a shared infrastructure of central queue managers and used individual clusters between application pairs to ensure that load balancing always works as expected whetehre the queue are on 1,2 or 4 of the central queue managers.

    The extensive use of MQ in hundreds of our applications has meant that or repos qmgrs are hosting the max number of clusters (255) and some of the app qmgrs are in up to 400 clusters. We are seeing performance problems with this approach as the level of cluster pub sub activity is so high and we have had a high level of disappearing queues from clusters as repositiories get out of step following incidnts processing the high volumes of messages.

    Queue based load balancing would allow us to implement the bare minimum of clusters but still ensure a predictable distribution of messages across the clstered queues. Currently any imbalance of clustered queues between the shared queue managers results in a skewed distribution.

  • Guest
    Dec 11, 2012

    The summary of the PMR shows that the title of this RFE is a bit misleading. This is nothing to do with pubsub; it's really about the fixed round-robin WLB that we have in MQ clusters.

    Basically, they have two queues Q1 and Q2 (which in this case happen to map to two subscriptions for the same topic). These queues are both defined on two queue managers (QM1 and QM2). When a message is published a copy is sent to each queue in turn. THe cluster workload management is working as designed, in that it is alternating the messages across the two channels. Unfortunately, having two channels and two copies of each message results in all the messages for Q1 going to QM1 and all the messages for Q2 going to QM2.

    This can be dealt with by putting the different queues in different clusters, with different channels - but we recognise that is very cumbersome.

    So we are considering adding another WLB capability to clusters that is based on the queue rather than the channel. Even a new simple "randomising" WLB algorithm as an alternative to the default round-robin would likely solve this.