| Author |
Message
|
| velocity |
 Posted: Fri Oct 16, 2009 6:08 am Post subject: MQ client connecting to DR MQserver. |
 |
|
Centurion
Joined: 30 Nov 2007
Posts: 126
|
Hello,
I have a situation where application running on MQ client will connect to QM1 and send msgs. When QM1 goes down it will be failed over to a DR QM2. Lets say if QM1 is running and then the application goes down, we would switch over to DR, but there will still be msgs stuck on QM1 when the switch over takes place. Any ideas as to how to make sure these msgs on QM1 do not get lost?
Thank you. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Fri Oct 16, 2009 6:30 am Post subject: Re: MQ client connecting to DR MQserver. |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| velocity wrote: |
| Any ideas as to how to make sure these msgs on QM1 do not get lost? |
Make sure the message are persistent. Then they will not be lost.
They'll be inaccessable until you fail back to QM1.
Now if you don't mean DR, but HA and "QM2" is a backup QM1, then there are published methods (and support pacs) for rebuilding the messages in the failed over queue manager.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| velocity |
| Posted: Fri Oct 16, 2009 6:33 am Post subject: |
|
|
Centurion
Joined: 30 Nov 2007
Posts: 126
|
| Quote: |
| Make sure the message are persistent. Then they will not be lost. |
How about I make the msgs not to expire, so when the app on QM1 is back up we can reconnect and get them? |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Oct 16, 2009 6:34 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Or consider moving to V7.0.1 and using a multi-instance queue manager.
_________________
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 |
|
|
| velocity |
| Posted: Fri Oct 16, 2009 6:38 am Post subject: |
|
|
Centurion
Joined: 30 Nov 2007
Posts: 126
|
| Sorry, I cant upgrade at this point. I was thinking of increasing maxqdepth so that msgs can stay there if the app makes them never to expire. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Oct 16, 2009 6:45 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| How about I make the msgs not to expire, so when the app on QM1 is back up we can reconnect and get them? |
Expiry is an MQMD field, and therefore an application programmer thing.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Oct 16, 2009 6:45 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| velocity wrote: |
| Quote: |
| Make sure the message are persistent. Then they will not be lost. |
How about I make the msgs not to expire, so when the app on QM1 is back up we can reconnect and get them? |
Non-persistent, non-expiring messages are not guaranteed to be available when a queue manager is restarted, especially if the queue manager in question crashed so badly function had to be switched to a DR site.
Only persistent messages are guaranteed to survive in this scenario.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Oct 16, 2009 6:47 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| velocity wrote: |
| I was thinking of increasing maxqdepth so that msgs can stay there if the app makes them never to expire. |
I'm not sure "thinking" is how I would describe this; there's no point having more space for messages if they can't survive.
Also setting a message not to expire when the application design says they do could have serious side effects.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Oct 16, 2009 7:25 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| exerk wrote: |
| Or consider moving to V7.0.1 and using a multi-instance queue manager. |
They are more an H.A. solution than a DR solution. I assume IBM assumes that both the primary and secondary Multi Instance QMs have access to the same files. DR locations are typically far away and have asynchronously updated storage.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Oct 16, 2009 7:31 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Making the messages persistent and non expiring in a very deep queue and assuming QM1 will eventually be available again is not a true DR plan. Assume your disaster will be Godzilla stomping on your datacenter till its a crumpled pile of smoldering debris - persistent non expiring messages on QM1 mean nothing to that lizard.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Oct 16, 2009 7:33 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| PeterPotkay wrote: |
| exerk wrote: |
| Or consider moving to V7.0.1 and using a multi-instance queue manager. |
They are more an H.A. solution than a DR solution. I assume IBM assumes that both the primary and secondary Multi Instance QMs have access to the same files. DR locations are typically far away and have asynchronously updated storage. |
Granted, but as velocity stated "...Lets say if QM1 is running and then the application goes down, we would switch over to DR..." I'm not so sure that DR is meant so much as stand-by infrastructure.
_________________
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 |
|
|
| PeterPotkay |
| Posted: Fri Oct 16, 2009 7:38 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
I guess when velocity said DR I assumed they meant DR and not H.A. 
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Oct 16, 2009 7:40 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| PeterPotkay wrote: |
| I guess when velocity said DR I assumed they meant DR and not H.A. |
Not many places I can think of that go DR because an application fails 
_________________
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 |
|
|
| PeterPotkay |
| Posted: Fri Oct 16, 2009 8:01 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
True. Read the original question again and don't know why the application would go to any other QM (H.A. or DR) if the app had a problem but QM1 was fine. They should just reconnect to QM1!
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| velocity |
| Posted: Fri Oct 16, 2009 8:05 am Post subject: |
|
|
Centurion
Joined: 30 Nov 2007
Posts: 126
|
| Quote: |
True. Read the original question again and don't know why the application would go to any other QM (H.A. or DR) if the app had a problem but QM1 was fine. They should just reconnect to QM1!
|
The app can go down for days together, maybe a week or so. That is why they need DR. I am sorry if I didnt make myself clear. |
|
| Back to top |
|
|
|
|
