Integration
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 (https://ideas.ibm.com).
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
Post an idea.
Get feedback from the IBM team and other customers to refine your idea.
Follow the idea through the IBM Ideas process.
Specific links you will want to bookmark for future use
Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.
IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.
ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.
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.
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.
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