Author |
Message
|
troy |
Posted: Thu Jan 08, 2009 5:56 am Post subject: Queue manager and broker coupling |
|
|
Novice
Joined: 07 Jan 2009 Posts: 20
|
Hi,
I want to understand the coupling between queue manager and broker.
Q1:
If the queue manger is stopped then does the broker also get stopped and no deplyment can be done on the broker.
Is the above statement correct?
Q2:
What strategy should be followed while deploying the message flow in the new servers in live?
Is the approach of disabling the Inbound and outbound queues and then deploying the message flow is fine or First broker to be stopped and then making queue manager stop + disable the queue then deploy the message flows and then restart the queue manager, broker and enable the queues?
Q3: According to my understanding if broker is stopped message flows cannot be deployed. Is this correct? |
|
Back to top |
|
 |
Vitor |
Posted: Thu Jan 08, 2009 6:06 am Post subject: Re: Queue manager and broker coupling |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
troy wrote: |
Q1:
If the queue manger is stopped then does the broker also get stopped and no deplyment can be done on the broker.
|
No. The broker will continue to try and run, filling it's error log as it goes. Deployment is possible, and will complete when the queue manager comes back up.
troy wrote: |
Q2:
What strategy should be followed while deploying the message flow in the new servers in live?
Is the approach of disabling the Inbound and outbound queues and then deploying the message flow is fine or First broker to be stopped and then making queue manager stop + disable the queue then deploy the message flows and then restart the queue manager, broker and enable the queues? |
You can't deploy with the queue manager stopped (see above). Why are you not simply deploying the new flows, what's with this convoluted "disablinfg queues" process?
troy wrote: |
Q3: According to my understanding if broker is stopped message flows cannot be deployed. Is this correct? |
No. The new deployment messages will still be deployed, and come into effect when the broker restarts. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
troy |
Posted: Thu Jan 08, 2009 6:17 am Post subject: |
|
|
Novice
Joined: 07 Jan 2009 Posts: 20
|
Thanks for the response.
As the deployment in live environment the idea here is to be safe so that new deployment won't hamper the existing funtionality.
I am confused with the answers of Q1 and Q2
Ans1 - From this ans u r telling that deployment is possible even the queue manager is stopped.
Ans2- You can't deploy with the queue manager stopped.
Could you please make it clear for me? |
|
Back to top |
|
 |
Vitor |
Posted: Thu Jan 08, 2009 6:22 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
troy wrote: |
Could you please make it clear for me? |
Apologies for my lack of clarity. You can deploy with the target queue manager or broker down; in the first instance the configuration message will sit on the xmitq until the qmgr is back, in the second on the command queue until the broker comes back. You can't complete the deployment until the broker restarts.
If the deployment is to a live environment you're more likely to cause a problem inhibiting queues. Why would this new deployment hamper exisiting functionality unless it changes the functionality (when it would need to be syncronised with the new applications changes, and that's a control issue not a WMB one). _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
troy |
Posted: Thu Jan 08, 2009 6:46 am Post subject: |
|
|
Novice
Joined: 07 Jan 2009 Posts: 20
|
Thanks for the clarification. |
|
Back to top |
|
 |
mqjeff |
Posted: Thu Jan 08, 2009 6:56 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
You can only deploy to a broker that has a stopped queue manager if the configuration manager is using a *different* queue manager.
You should generally not expect a broker to do much useful work at all if it's queue manager is down. Some fair, and increasing, amount of stuff "under the covers" uses MQ. Likewise with the Broker database, although this is a decreasing amount of stuff, rather than an increasing amount of stuff.
Keep the broker's queue manager running while the Broker itself is running. Keep the broker's database running while the Broker itself is running.
Don't take the wheels off your car while driving down the highway.
Broker deployments are very sensible and can be relied on to do the right things regarding inflight transactions. Everything else is a question of governance. |
|
Back to top |
|
 |
WBI_User21 |
Posted: Thu Jan 08, 2009 8:40 am Post subject: |
|
|
 Voyager
Joined: 12 Jun 2007 Posts: 98
|
As I understand , question is about incremental deployment.
How can one do incremental deployment of message flows, when flows are listening load balance cluster queues .Do I need to put disable the cluster queues of particular broker domain to which the message flows are listening to and proceed with deployment so that there is no loss of messages /SLA violation or there is any other better strategy. |
|
Back to top |
|
 |
Vitor |
Posted: Thu Jan 08, 2009 9:08 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
WBI_User21 wrote: |
Do I need to put disable the cluster queues of particular broker domain to which the message flows are listening to and proceed with deployment so that there is no loss of messages /SLA violation or there is any other better strategy. |
There is a better strategy - leave the queues alone and let the broker do it's job! As my respected associates says, provided you have governence of the changes the broker will sort everything else out. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
|