| Author |
Message
|
| PEPERO |
 Posted: Wed Aug 24, 2016 4:19 am Post subject: Node and flow additional instances |
 |
|
Disciple
Joined: 30 May 2011
Posts: 177
|
Hi all;
What is the added value of using additional instance of node instead of additional instance of the flow? |
|
| Back to top |
|
 |
| ghoshly |
| Posted: Wed Aug 24, 2016 9:24 am Post subject: |
|
|
Partisan
Joined: 10 Jan 2008
Posts: 333
|
| Both thread pools are different from where additional threads are allowed. When more number of parallel input connections are required, I used the node pool and when over all flow processing throughput is required, I used additional instances of the flow. I would be glad as well if better explanation is received from seniors. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Aug 24, 2016 9:36 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Each node is a process.
Each instance of a flow is a thread in a process.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| Craig B |
| Posted: Tue Sep 20, 2016 1:13 am Post subject: |
|
|
Partisan
Joined: 18 Jun 2003
Posts: 316
Location: UK
|
When you have one node in a message flow it doesn't make any difference. It comes into play when you have multiple input nodes in a flow. If you rely on flow level additional instances then one input node can "steal" most of the threads, leaving other input nodes under resourced.
Historically, this functionality was added for Aggregation. In the old days IIB users used to implement their Request and Reply logic in the same flow. More often than not the Request leg would consume a large number of thread pool leaving the Reply side starved and unable to keep up. This was solved by adding node level additional instances to the product. That meant the reply side input nodes could be given what they needed to keep up with the request side.
Please be aware that if you are using IIB V10 and you have input nodes in a subflow that have node level additional instances, there has been a recently discovered defect in this area such that the additional instances did not get applied to the input node.
_________________
Regards
Craig |
|
| Back to top |
|
|
| DeadPool |
| Posted: Thu Sep 29, 2016 12:46 am Post subject: |
|
|
Apprentice
Joined: 27 May 2016
Posts: 30
|
| Craig B wrote: |
Please be aware that if you are using IIB V10 and you have input nodes in a subflow that have node level additional instances, there has been a recently discovered defect in this area such that the additional instances did not get applied to the input node. |
Craig do you have any more information on this? Is IBM working on it? |
|
| Back to top |
|
|
| Craig B |
| Posted: Thu Sep 29, 2016 1:51 am Post subject: |
|
|
Partisan
Joined: 18 Jun 2003
Posts: 316
Location: UK
|
The APAR is:
IT15164: IF INPUT NODE OF THE MESSAGE FLOW IS PART OF A SUBFLOW THEN ADDITIONAL INSTANCE THREADS ARE NOT SPAWNED
As of yet it has not made it into any IIB V10 fixpacks.
However, you can request a fix for this via a PMR
_________________
Regards
Craig |
|
| Back to top |
|
|
| mehta10987 |
| Posted: Sat Oct 19, 2019 12:44 pm Post subject: Node and flow additional instances |
|
|
Novice
Joined: 12 Oct 2019
Posts: 13
Location: USA
|
I have scenario with two Main Flows in one App
Flow1 --> File Input Node(with only one instance) Reading a large file and reading records to put messages into a Queue.
Flow2 --> MQInput Node (multiple instances with Node) reading messages and further activities (calling three backend services) and writing Success and failures Report to two different files through File Output Node.
However the writing success and failure records into two diff files is getting through the subflow.
I am using multiple instances approach for MQInput Node.
IIB version is V10.
Any comments or suggestions  |
|
| Back to top |
|
|
| timber |
| Posted: Sun Oct 20, 2019 10:45 am Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1292
|
Not sure about anybody else, but I have no idea what this sentence means:
| Quote: |
| the writing success and failure records into two diff files is getting through the subflow |
I have no idea which 'subflow' you are talking about, and I do not know what you mean by 'getting through the subflow'. You will need to supply a *lot* more information if you want to get a useful answer. |
|
| Back to top |
|
|
| mehta10987 |
| Posted: Sun Oct 20, 2019 7:21 pm Post subject: Node and flow additional instances |
|
|
Novice
Joined: 12 Oct 2019
Posts: 13
Location: USA
|
Sorry for not making statement clear enough
Flow1 --> File Input Node(with only one instance) Reading a large file and reading records to put messages into a Queue.
Flow2 --> MQInput Node (multiple instances with Node) reading messages and further activities (calling three backend services) and writing Success and failures Report to two different files through File Output Node.
In Flow 2 there is a subflow where either records are written into
a Success File or
an Error File where failed records with Error Code/Description/Transaction ID/ Actual record is logged so that business can have a look and work on those failures. |
|
| Back to top |
|
|
| timber |
| Posted: Mon Oct 21, 2019 1:43 am Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1292
|
|
| Back to top |
|
|
| mehta10987 |
| Posted: Mon Oct 21, 2019 5:16 am Post subject: |
|
|
Novice
Joined: 12 Oct 2019
Posts: 13
Location: USA
|
Hello Timber,
Actually there were two questions
One was over the SLEEP approach for the current business functionality to be achieved.
Second: What would be better approach to finish the file(records) processing. Mutithreading of MQ Input Node at Second Flow, OR creating multi instances of overall second Flow. |
|
| Back to top |
|
|
|
|
