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 Future consideration
Workspace App Connect
Created by Guest
Created on Apr 8, 2015

IIB consumes all available Instances before recycling any previous ones

The thread despatch model used in Message Broker / IIB causes new processing threads / flow instances to be initialised ahead of current / previously processing threads being closed-down.

This can cause a spin-up of active processing threads / flow instances, up to the maximum number of additional instances configured.

...which in turn can lead to a performance degradation as further and further system resources are allocated to more and more threads (potentially unnecessarily).

...Newly initialised threads that are ready-to-go may be opted for ahead of previously utilised threads which are now dormant.
...Previously utilised threads may not be reused / recycled until all available additional instances have been initialised / consumed.

Idea priority Medium
RFE ID 69307
RFE Product IBM App Connect Enterprise (formerly IBM Integration Bus)
  • Guest
    Mar 11, 2021

    RFE Review. As part of our standard process for reviewing RFEs we have recently discussed this RFE and wish to note that it remains of long term interest to us. Nothing has changed architecturally in this area with the more recent engineering release of the IIB/ACE technology and we think there would still be value in letting users constrain the rate at which new threads are added to the pool. Whilst not particularly popularly demanded, we will continue to monitor this RFE and keep it in mind for future plans. Status is maintained as Uncommitted Candidate.

  • Guest
    Jul 15, 2016

    Hi Roberto,

    Thanks for raising this RFE concerning the current IIB thread dispatch process.

    Currently, when a flow thread retrieves a message from its transport it immediately dispatches another thread to look for more work. When a large number of additional instances are specified it is possible for many threads to be dispatched before the first thread has finished processing its message. This means that you can reach 256 additional instances, even in situations where you don't have 256 input messages. Using our current dispatch model you would only need 128 input messages for each one of them to spin off another thread to go looking for work. Once the 256 threads have been created by IIB they remain in the thread pool for as long as the flow is deployed/running. As I understand it, in the PMR you raised you were advised to reduce the number of additional instances on the flow but you don't like this approach as you would like 256 as a theoretical maximum for your largest work load.

    To paraphrase the RFE, you only want to have 256 threads running in the system if you have more than 256+ input messages to process, and you'd be willing to wait for a short period of time for an active thread to return to the pool before dispatching another one. As such, one possible solution implementation would be to have a dispatcher thread that was responsible for monitoring the input source and only dispatching a new thread after a specified time frame. This is closely linked with an idea that has come up in other client conversations of being able to destroy active threads after an idle time period.

    Status of the RFE is updated to Uncommitted Candidate.

  • Guest
    Oct 7, 2015

    Due to processing by IBM, this request was reassigned to have the following updated attributes:
    Brand - WebSphere
    Product family - Integration
    Product - IBM Integration Bus (WebSphere Message Broker) - IIB

    For recording keeping, the previous attributes were:
    Brand - WebSphere
    Product family - Connectivity and Integration
    Product - IBM Integration Bus (WebSphere Message Broker) - IIB