| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| put disable enable on a cluster queue |
« View previous topic :: View next topic » |
| Author |
Message
|
| exerk |
 Posted: Wed Jan 14, 2009 4:33 am Post subject: |
 |
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| aditya.aggarwal wrote: |
| We have stopped the channel as we are doing migration of application from one platform to other platform... |
So next time you do this:
1. Get the application and WMQ infrastructure ready on the migration platform and when you introduce the queue managers into the cluster ensure the queues are PUT(DISABLED).
2. Temporarily stop the application that produces the messages and drain the queues using the to-be-migrated application.
3. PUT(DISABLE) the queues in the queue managers that are to be decommissioned, then PUT(ENABLE) the queues in the migration platform queue managers.
4. Restart the message producing application.
5. Drop the 'old' queue managers from the cluster.
A bit of forethought and planning can save a lot of unnecessary effort - doing what you did built in problems to what from the sound of it should have been a simple and straightforward migration.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed Jan 14, 2009 4:37 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| aditya.aggarwal wrote: |
| If we have not stopped the channels then the message have been flown to SYSTEM.DEAD.LETTER.QUEUE. That's why we have stopped the channels. |
a) Not if the queues were put disabled and b) what's the problem with them being on a dead letter queue and c) why can't the putting application be stopped?
| aditya.aggarwal wrote: |
Issue is little bit differnt at QM3 now..
...
CLUSQMGR(SYSTEM.TEMPQMGR.BROKERDEMO1.NET(512000))
|
This points to a channel problem
| aditya.aggarwal wrote: |
start chl(TO.QM2.QM_CLUSTER)
2 : start chl(TO.QM2.QM_CLUSTER)
AMQ8227: Channel TO.QM2.QM_CLUSTER not found.
|
This is the channel problem
| aditya.aggarwal wrote: |
| Any clue on this? |
I think the errors are a clue in themselves.... 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| aditya.aggarwal |
| Posted: Wed Jan 14, 2009 4:48 am Post subject: |
|
|
Master
Joined: 13 Jan 2009
Posts: 252
|
Many thanks Vitor..
We have resolved the issue at QM3 after re-starting the cluster channels. It was in retrying stage at FR.
We can not store the message in DLQ, as message flow is very huge.. long duration of Database Synchrnization , may messed up the DLQ...apart from that we can not stop the application...as it is not only putting message in this queue manager queue...Lot's of other inhouse application/QM are depand on this.
Thanks to all...for helping me to resolve this issue. 
Cheers..
Aditya A |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jan 14, 2009 5:17 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| aditya.aggarwal wrote: |
| We can not store the message in DLQ |
If this is really the case, then pray to whatever gods you believe in you never get an undeliverable message! 
| aditya.aggarwal wrote: |
| , as message flow is very huge.. |
This is easy enough to resolve.
| aditya.aggarwal wrote: |
| long duration of Database Synchrnization , |
You have badly positioned UOW boundaries which are probably impacting database throughput
| aditya.aggarwal wrote: |
| may messed up the DLQ |
You can't mess up a queue by putting messages on it
| aditya.aggarwal wrote: |
| ...apart from that we can not stop the application |
Include in your prayers you never get a program bug or hardware failure, both of which will stop your application quite effectively
| aditya.aggarwal wrote: |
...as it is not only putting message in this queue manager queue...Lot's of other inhouse application/QM are depand on this.
|
And all of them should be able to cope with outages and a lack of messages.
Even given all this, exerk is quite right; proper planning and forethought would have prevented all of this. Minimal prior research would have revealed to you that your method was fatally flawed.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
