| Author |
Message
|
| MQ_NOBISH |
 Posted: Tue Apr 09, 2013 11:24 pm Post subject: Managing additional instances programmatically |
 |
|
Newbie
Joined: 09 Apr 2013
Posts: 2
|
Hi,
I want to manage the additional instances using ESQL codes and not through the BAR file.Will i be able to to do and monitor it???? plz help.  |
|
| Back to top |
|
 |
| adubya |
| Posted: Tue Apr 09, 2013 11:25 pm Post subject: |
|
|
Partisan
Joined: 25 Aug 2011
Posts: 377
Location: GU12, UK
|
| You cannot do this via ESQL. |
|
| Back to top |
|
|
| Esa |
| Posted: Tue Apr 09, 2013 11:44 pm Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
Managing additional instances is an administrative task, not the programmer's.
But you can get the number of additional instances set by the administrator. If that's whan you mean with 'monitoring'.
So if you want to force the flow to run with no additional instances, you can throw an exception if the flow has additional instances defined in runtime. That will force the administrator to redeploy the flow with no additional instances.
That's about all you can do for additional instances as a developer. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Apr 10, 2013 3:07 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| adubya wrote: |
| You cannot do this via ESQL. |
You would need at least some basic Java knowledge as well.... |
|
| Back to top |
|
|
| Esa |
| Posted: Wed Apr 10, 2013 5:39 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| mqjeff wrote: |
| adubya wrote: |
| You cannot do this via ESQL. |
You would need at least some basic Java knowledge as well.... |
Correct. with java you can create a flow that administers itself. Or a deadlock. Do some testing and you will find out which one comes more easily.
Why would you make the flow adjust the number of additional instances? So that you could add instances when there is more load?
Just give the flow enough additional instances (not too many, though) and the broker will do everything for you. It will only allocate additional threads if needed. |
|
| Back to top |
|
|
| MQ_NOBISH |
| Posted: Thu Apr 11, 2013 1:09 am Post subject: |
|
|
Newbie
Joined: 09 Apr 2013
Posts: 2
|
| Thanks,That means to manage this i will neeed to call a java procedure inside ESQL. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Apr 11, 2013 2:32 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| MQ_NOBISH wrote: |
| Thanks,That means to manage this i will neeed to call a java procedure inside ESQL. |
No.
It means to manage this, you need to do the correct thing, which is not manage this from within your flow.
The only reasonable purpose for having a flow alter it's own additional instances is so that it can decide that *too many* instances are in use, and reduce the number temporarily.
But that change won't take immediate effect, and requires a fair amount of *stateful* knowledge that most flow don't have, since they are *stateless*.
As has been said, if you deploy a flow to use 100 additional instances, and you only send it one message every 10 minutes, it will only *ever* use one single instance. The second you send it 100 messages, it will then use all 100 instances... and then when those 100 messages have been processed and at least one minute has elapsed... you will be back to having a single instance.
Broker manages this for you!
Don't change it from your code. Really. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Thu Apr 11, 2013 2:58 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| mqjeff wrote: |
Don't change it from your code. Really. |
At the risk of repeating myself (from a previous thread)
'But the requirement is....'
(slightly jaded from battling with some idiots who think that Broker === WAS and that all their J2EE code will run inside it without changes)
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Apr 11, 2013 4:55 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| MQ_NOBISH wrote: |
| Thanks,That means to manage this i will neeed to call a java procedure inside ESQL. |
No, this means to manage this you need to realise you neither need or want to manage this.
Unless you can explain very clearly and convincingly why the in-built features of the broker product which manage this for you do not work for your use case.
A response of "my requirment is to manage it programatically" does not qualify as a clear or convincing use case. Or a use case of any kind.
You should also understand (as should whoever's asking you to do this) that as my most worthy associates have pointed out, trying to do this is very likely to blow up in your face.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Thu Apr 11, 2013 5:15 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| Vitor wrote: |
| the in-built features of the broker product |
@MQ_NOBISH
Why are you dissatisfied with the current way WMB manages its performance? What have you observed that is inadequate?
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
|
|
