| Author |
Message
|
| zpat |
 Posted: Thu Aug 05, 2010 1:14 am Post subject: Deploying message flows in stopped state? |
 |
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
I want to separate (in time) the deployment of message flows with their start of their execution.
Can I deploy a flow into an immediately stopped state, so it does not start until manually started later? |
|
| Back to top |
|
 |
| kash3338 |
| Posted: Thu Aug 05, 2010 3:00 am Post subject: |
|
|
Shaman
Joined: 08 Feb 2009
Posts: 709
Location: Chennai, India
|
| You can try with Configuration Manager Proxy API's. With that you have options to deploy to a Broker with setting few parameters in it. |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Aug 05, 2010 3:02 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| Developing own code for this is not an option. I see this option as a fairly obvious one really. Perhaps I should raise a product requirement. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sat Aug 07, 2010 1:25 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
If they use MQInput nodes, you could Get Inhibit the queues to accomplish basically the same thing.
But yes, I agree this is a desirable option.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Aug 07, 2010 2:06 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
 I'll second that. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqjeff |
| Posted: Sat Aug 07, 2010 7:25 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
...
What's the purpose behind doing this?
I mean... is the desire to know that a deployment has succeeded before you go home for the day and that it will not go live until the designated time?
Is it a desire to perform an automatic cutover from one version to another?
I don't really understand the purpose behind the task of performing a deployment of a stopped resource. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Sat Aug 07, 2010 10:29 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
Perhaps they are deploying a flow that is 'normally' stopped letting messages build up on a queue ready for processing during a set time window.
If there are messages on the input q deploying a new version of the flow will automatically start their processing which may break other systems.
I'm with Vitor here.
Just set Get inhibit on the input Q. But you may have to explain to the MQ/Sys Admins why the flow threw some MQ 2016 errors
_________________
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: Sun Aug 08, 2010 12:01 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
One example is our DR broker, we want it ready for action, all loaded up with flows, but not processing.
With MQ driven flows, one can ensure nothing is inadvertantly processed by clearing the queues (or inhibiting). But with timer nodes and such like, this is not so predictable. For example a flow may access a database and start processing data as soon as it is started.
Especially with DR we would not want this. But we do want the deployment team (who are not the WMB admin team) to do their part in advance, rather than have to work it all out during the stress of a real DR scenario.
It's about having control, we might also want deployment to be done in advance (and by another team) of the go-live date/time for a new production implementation.
Lots of reasons really but the warm standby DR is the most obvious example. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Sun Aug 08, 2010 1:42 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
Are you sending all your data to this broker via WMQ?
If so, is it coming from a remote QM? (via channels)
If so then just make sure the Channels are stopped.
So given your scenario, The DR broker is all there good to go and with all the flows stopped.
Ok. What happens to the data that is put on one or more input queues?
Is it lost forever?
IMHO, in your case I'd look for other ways to stop data from being deposited (aka sent via MQ, SOAP Http or whatever). This way you don't lose any data.
_________________
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: Sun Aug 08, 2010 1:47 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
No, exactly my point (sorry if it was not clear), that modern flows are not all MQ driven.
Some start all by themselves with timer nodes, that is the problem.
Anyway we know IBM didn't provide this, although to me is it a very obvious thing to offer and simple to code for them.
It's more relevant for command driven deploys than GUI but the option on either would be ideal.
Yet another reason is flow interdependency, if you don't want to start one until another is ready (and we know that deploys can take a long time). |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sun Aug 08, 2010 9:12 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Jeff,
Our specific requirement would be around flows with File Input Nodes. Since we have multiple brokers, we can only have the flow in one Broker running to avoid duplicate processing off of the files on the remote server.
But we want to have the flow deployed, stopped and ready to go on our second broker just in case there is a catastrophic failure on the the first Broker - the VCS cluster for that Broker fails or something. In that case we don't want to be rushing around trying to get the bar file located in PVCS and deployed. Mush faster just to start the stopped flow.
But when new versions are deployed, we have to immediately stop that flow on the second broker once the deploy is done. Before we can, there's always the risk of both flows grabbing that same file. Low risk, since the deploys are happening during quiet time, but still a risk.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Amitha |
| Posted: Mon Aug 09, 2010 8:46 am Post subject: |
|
|
Voyager
Joined: 20 Nov 2009
Posts: 80
Location: Newyork
|
| Quote: |
| But we want to have the flow deployed, stopped and ready to go on our second broker just in case there is a catastrophic failure on the the first Broker - the VCS cluster for that Broker fails or something. In that case we don't want to be rushing around trying to get the bar file located in PVCS and deployed. Mush faster just to start the stopped flow. |
Peter,
From what I understand this is high availability scenario, assuming it is active and passive setup. You have both the Flows deployed on both the servers. The passive will start listening to file directory or to queues only after it becomes active. Isn't this correct? Correct me if I am wrong. |
|
| Back to top |
|
|
| mkza.swe |
| Posted: Tue Jul 10, 2012 9:53 am Post subject: Re: Deploying message flows in stopped state? |
|
|
Novice
Joined: 04 Jun 2012
Posts: 16
|
| zpat wrote: |
I want to separate (in time) the deployment of message flows with their start of their execution.
Can I deploy a flow into an immediately stopped state, so it does not start until manually started later? |
Hi!
2 years later, and I'm looking for the same option. Using WMB 7.x and can not find a way to do it. Anyone know if the option to deploy into a stopped state has been added since the initial post, and then how?
Cheers! |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Tue Jul 10, 2012 10:10 am Post subject: Re: Deploying message flows in stopped state? |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| mkza.swe wrote: |
| zpat wrote: |
I want to separate (in time) the deployment of message flows with their start of their execution.
Can I deploy a flow into an immediately stopped state, so it does not start until manually started later? |
Hi!
2 years later, and I'm looking for the same option. Using WMB 7.x and can not find a way to do it. Anyone know if the option to deploy into a stopped state has been added since the initial post, and then how?
Cheers! |
Why don't you create your own post rather than hijack a two year old thread. Or go to class to find out.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| mkza.swe |
| Posted: Tue Jul 10, 2012 10:23 am Post subject: Re: Deploying message flows in stopped state? |
|
|
Novice
Joined: 04 Jun 2012
Posts: 16
|
| lancelotlinc wrote: |
| Why don't you create your own post rather than hijack a two year old thread. Or go to class to find out. |
Well, I thought it was good forum manner to use the threads that are there instead of creating extra redundant threads.
And thank you, I went to class. I am IBM certified already.
Anyway... Thank you for helpful and constructive post. |
|
| Back to top |
|
|
|
|
