| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Order of starting execution groups |
« View previous topic :: View next topic » |
| Author |
Message
|
| zpat |
 Posted: Thu Apr 12, 2012 11:48 am Post subject: Order of starting execution groups |
 |
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
I have been asked if it is possible to control the order of execution group startup - so that execution group B is only started once execution group A is up.
My response was that this is not even desirable (as a design), let alone possible, but I would be interested in anyone who has solved a similar issue.
I tend to think that this is another example of WMB being used as an apps server and not as middleware. The most harmless idea I have is to insert a ESQL sleep into the flows that want to start later.
WMB 7003 on AIX. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu Apr 12, 2012 12:05 pm Post subject: Re: Order of starting execution groups |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| zpat wrote: |
| I tend to think that this is another example of WMB being used as an apps server and not as middleware. |
Or management looking at a dependancy diagram.
If this is actually a problem that needs solving, then what you need to do is find out why execution group A takes so long to start that all the dependant flows in execution group B time out waiting for it, or why the timeouts in execution group B are set so short.
Could it be badly phrased? That execution group B starts and runs only if execution group A is running, i.e. if execution group A crashes execution group B stops processing until it's back? That would be marginally less bonkers but easily fixed by the deft deployment of a few WMQ queues and some monitoring.
As to your original point, AFAIK it's not possible to impose an order. I may not know far enough.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Thu Apr 12, 2012 9:56 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
If all you want to achieve is to delay the start of processing of messages
AND
all the flows start with an MQInput Node then you could always GET_INHIBIT the queues until the other EG has commenced processing messages.
Being realistic, starting an EG and its deployed flows is a complicated process. Some of the things that MIGHT well have to be done are :-
Load the MessageModels specified in the Input Nodes into Memory
Start the HTTP, HTTPS Server for SOAP
Start the HTTP, HTTPS Server for HTTP
Create the TCPIP Server Listening Environment
Initialise the various heaps and pools.
There is a lot going on. Naturally, an EG with a big mix of flows and say 50+ flows is going to take a lot longer to startup than those with just a few MQInput driven flows.
I've seen a broker (V6.1) take 40+ minutes to startup and reach a quiescent state. Several times an EG would restart because the ConfigMgr had not received a response saying "I'm up" within the time limit. This is all due to resource contention. Restarting a single EG while the broker was running was pretty quick (relatively). It all came down to using inadequate H/W (CPU Grunt) for the job.
At those times, I did feel that a way to schedule the startup of each EG would have been preferable to the 'All at once' method currently used.
Sadly, this does not seem possible with the current Broker releases.
Time for an improvement request maybe?
_________________
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 |
|
|
| zpat |
| Posted: Fri Apr 13, 2012 12:19 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Alternatively WMB could load everything up - and only when all EGs were ready for the "off", actually fire the starting gun.
Currently the approach is "Gentlemen, start your engines"... 
I don't like the idea of inhibiting queues and so forth because it would make both routine stop/starts and HA failovers a lot more complex.
Better error/exception/retry logic in the flows would really be desirable - but too many developers don't consider the possible real-world issues when they code up flows.
The use of allegedly modern protocols like Web Services has made the problem worse. Good old MQ can just buffer the different flows and you don't need to wait because the response message can start another flow. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Fri Apr 13, 2012 5:39 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
