| Author |
Message
|
| visasimbu |
 Posted: Thu Jan 25, 2018 11:14 pm Post subject: Additional instance is not increasing |
 |
|
Disciple
Joined: 06 Nov 2009
Posts: 171
|
I have created a application of two message flows named F1.msgflow and F2.msgflow. F2 msg flow will receive huge volume of messages. Hence I have increased the number of instance to 3 by below steps.
1) Created bar file.
2) Open bar file in Integration development perspective.
3) Expanded application and clicked on the message F2.
4) In property window, under Workload managment->Additional Instance was 0. I have changed to 3.
5) Save bar file and deployed.
After increasing the instance to 3, my IPProc of F2 msg flow input queue was 1. I expected it should be 3. Since i have additional instance of 3. Though my input queue of F2 has huge backlog 2000 messages.
Why instance is not getting increased in my case ?
I am using IIB v9.0.0.6
Advance thanks for kind help ! |
|
| Back to top |
|
 |
| abhi_thri |
| Posted: Fri Jan 26, 2018 1:01 am Post subject: |
|
|
Knight
Joined: 17 Jul 2017
Posts: 516
Location: UK
|
Can you try verifying that the 'Additional Instances' is indeed set to 3 for the deployed flow either via connecting to broker from toolkit or via webgui. If additional instances is set to 3 and there are eligible messages on the queue then you should see IPProc count as 4 (additional instances +1).
Another possibility is that even you are you seeing the curdepth as 2000 those may not be committed yet by the PUT app (eg:- in case it is putting as batches) |
|
| Back to top |
|
|
| zpat |
| Posted: Fri Jan 26, 2018 1:41 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Additional means "in addition to". So if you change it from 0 to 3, would expect 3 IN ADDITION to the usual one, i.e. 4 in total.
Additional instances are only started on demand (so I believe), in other words when a message comes in and no flow is waiting to process it.
You would probably be better off using workload management policies rather than editing the bar file.
Either way - check it using MBX or Web Admin.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jan 26, 2018 5:47 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| zpat wrote: |
| Additional means "in addition to". So if you change it from 0 to 3, would expect 3 IN ADDITION to the usual one, i.e. 4 in total. |
| zpat wrote: |
| Additional instances are only started on demand (so I believe), in other words when a message comes in and no flow is waiting to process it. |
You're correct in that they're only started on demand, though more modern versions of IIB provide an option to start all additional instances when the flow starts. It's fun watching a numpty who selected that option and 200 additional instances waiting for his flow to eventually get going.....
My point is that they're started on demand, where demand is "if the EG thinks it needs them". If the flow is chewing through at a good clip within the service interval, you may not see any additional instances and almost certainly won't see the maximum possible number.
| zpat wrote: |
| You would probably be better off using workload management policies rather than editing the bar file. |
Easier, more flexible and future proof.
| zpat wrote: |
| Either way - check it using MBX or Web Admin. |
again
What's the actual additional instances set on the deployed flow? I also agree with the previous suggestion of checking that these 2000 messages are actually committed and available.
Look for the simple problem first.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| visasimbu |
| Posted: Sat Jan 27, 2018 10:38 am Post subject: |
|
|
Disciple
Joined: 06 Nov 2009
Posts: 171
|
| abhi_thri wrote: |
| Can you try verifying that the 'Additional Instances' is indeed set to 3 for the deployed flow either via connecting to broker from toolkit or via webgui. If additional instances is set to 3 and there are eligible messages on the queue then you should see IPProc count as 4 (additional instances +1). |
I Agree. It is my mistake. It is expected as number 4.
| abhi_thri wrote: |
Another possibility is that even you are you seeing the curdepth as 2000 those may not be committed yet by the PUT app (eg:- in case it is putting as batches)
|
Thanks for your reply ! 
Yes. The F1.msgflow sending as batches.
Changed transaction mode of MQOutput to 'No' from 'Automatic' in my F1.msgflow.
Once again thanks for your help !!!
Last edited by visasimbu on Sat Jan 27, 2018 10:58 am; edited 2 times in total |
|
| Back to top |
|
|
| visasimbu |
| Posted: Sat Jan 27, 2018 10:42 am Post subject: |
|
|
Disciple
Joined: 06 Nov 2009
Posts: 171
|
| zpat wrote: |
Either way - check it using MBX or Web Admin. |
Thanks for your reply. Since our Prod brokers are in UNIX system and no access to MBX users or Web Admin.
The instances increases should go via bar file. Hence we are looking for instance incremental in bar file. |
|
| Back to top |
|
|
|
|
