|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
Automatically start multiple instances of a Flow |
« View previous topic :: View next topic » |
Author |
Message
|
x061294 |
Posted: Tue Nov 06, 2007 2:58 am Post subject: Automatically start multiple instances of a Flow |
|
|
 Acolyte
Joined: 05 Apr 2005 Posts: 62
|
Is there a way to force, in version 6 on Linux Intel, multiple instances of a flow to start up upon broker start?
I ask because I want to start my flow with a timer node, with a 1 second interval. This way I can poll a database for any inserts and act upon them as quickly as possible. We went down the approach of having the Database (Oracle) send the message in to the broker, but it's smallest window was 1 second as well. We also took a look if we could have a trigger on the DB fire off the data via WS since that doesn't have the polling issue, but, then we tie up future inserts waiting for the WS to finish.
We're resigned to polling the DB, so to keep the control in 1 place we're going to have the broker do the polling since it will do the rest of the work within the scope of a transaction. However, even 1 second of polling time means that I lose potentially .99 seconds of time after an insert, and, when I only have a 3 second SLA to get the data out of the DB and up to another system, after doing processing on it, wasting .99 seconds is a lot.
My question/thought would be, can we start up two instances of the flow automatically? I know they wouldn't be polling exactly .5 seconds apart, but, it gives me a warmer and fuzzier feeling knowing that I've shrunk the window down a little at least.
Ideally I'd like to start a number of instances when peak processing is going on so that I have instances always looking to pull data off the DB as fast as it arrives, and then lower that number so I'm not just buring cycles when no records are being written during off peak. Don't know if that will require too much ongoing deployment effort though. |
|
Back to top |
|
 |
Michael Dag |
Posted: Tue Nov 06, 2007 3:17 am Post subject: |
|
|
 Jedi Knight
Joined: 13 Jun 2002 Posts: 2607 Location: The Netherlands (Amsterdam)
|
last time I worked with the multiple instances, it regulates itself automatically, i.e. starts with 1 instance and when the queue gets 'full'er multiple instances upto the maximum specified fire up, when the queue depth decreases so will the number of instances. _________________ Michael
MQSystems Facebook page |
|
Back to top |
|
 |
jefflowrey |
Posted: Tue Nov 06, 2007 3:18 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
Well, if you configure the Timer nodes to fire at 1 second intervals, and you start two instances at the same time... they'll both fire one second later...
But you knew that.
Yes, when you deploy, you can configure how many additional instances you want your flow to use.
If that doesn't do the trick, then you can deploy the same flow to multiple EGs. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
x061294 |
Posted: Tue Nov 06, 2007 3:45 am Post subject: |
|
|
 Acolyte
Joined: 05 Apr 2005 Posts: 62
|
I thought about the additonal EG approach. Wanted to stay away from it if I can. I was/am hoping that there was some way to force the instances rather than let Broker figure it out. Broker figuring it out works fine when some outside force is banging on it's door, and it realizes it needs to open the door more often, so it scales the number of instances. But for these polling type of situations, it's up to Broker to set the instances, not someone else knocking on the door. So I amhoping there isa way to force the issue. |
|
Back to top |
|
 |
jefflowrey |
Posted: Tue Nov 06, 2007 3:51 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
Remember that the TimoutNotification node is an Input node.
I haven't verified it, but it's a two minute test to do so, but I'm reasonably sure that each additional instance of a flow with a TimeoutNotification node will create an additional thread that is running as long as the TimeoutNotification node is supposed to trigger at some time in the future. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
Tasse |
Posted: Fri Nov 09, 2007 7:15 am Post subject: |
|
|
Newbie
Joined: 09 Nov 2007 Posts: 2
|
An other and quite easy solution would be using an MQInput node to receive messages that trigger the polling, and the schedule a job that puts trigger messages on the input queue of the flow, say every 300 milliseconds.
Alternatively, start a background job that keeps running and sending trigger messages on regular intervalls.
This way you get rid of the limit of 1 seconds timer resolution.
Yet an other (a bit strange perhaps) solution could be to start the flow with a trigger message, let the flow do its polling and other tasks and finally let the flow thread wait some milliseconds (e.g. in a Java compute node) and redirect the original trigger message back to the input node so it all start over again. In other words, the same trigger message loops through the flow over and over again wiht some delay between loops. |
|
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
|
|
|
|