| Author |
Message
|
| nimbleron |
 Posted: Thu May 07, 2015 9:43 am Post subject: Detecting Input Procs=0 and moving messages to another QM |
 |
|
Newbie
Joined: 07 May 2015
Posts: 4
|
Consider the situation where we have 2 clustered queue mangers QM1 and QM2. Each has a local cluster queue (LQ). Application 1 (APP1) connects to QM1 and does a get with wait on LQ. Application 2 (APP2) connects to QM2 and does a get with wait on LQ.
In the situation where APP1 dies, and messages are left on that local cluster queue on QM1, is there any WMQ capabilty that detects the connection has died and moves those messages to QM2 so that they can be processed by APP2?
I recall reading something about that at one time but now am wondering if I was dreaming.
Thanks. |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Thu May 07, 2015 9:45 am Post subject: Re: Detecting Input Procs=0 and moving messages to another Q |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| nimbleron wrote: |
| is there any WMQ capabilty that detects the connection has died |
Yes
| nimbleron wrote: |
| moves those messages to QM2 so that they can be processed by APP2? |
No |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu May 07, 2015 11:14 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
Ideally and to have redundancy, app1 should connect to both QM1 and QM2 and service the queue. The same way app2 should connect to both QM1 and QM2 and service the queue. This way if one app dies the other will pick up the messages... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu May 07, 2015 11:34 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
How does APP1 die and no-one notice? And try to restart it?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| tczielke |
| Posted: Thu May 07, 2015 11:52 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 939
Location: Illinois, USA
|
It sounds like nimbleron was referring to the amsclm sample.
_________________
Working with MQ since 2010. |
|
| Back to top |
|
|
| nimbleron |
| Posted: Thu May 07, 2015 12:51 pm Post subject: |
|
|
Newbie
Joined: 07 May 2015
Posts: 4
|
| fjb_saper wrote: |
| Ideally and to have redundancy, app1 should connect to both QM1 and QM2 and service the queue. The same way app2 should connect to both QM1 and QM2 and service the queue. This way if one app dies the other will pick up the messages... |
A solution pattern I try to follow is to not solve a problem that is solved in some vendor application or application component. So in this case, I'm first looking for IBM WMQ to solve this problem for me.
If WMQ does not solve the problem then things get ugly. Consider 5 Queue Managers and 5 Apps with each App needing to have 5 connections, one to each QMGR. That's unruly.
Thanks for the information though. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu May 07, 2015 2:06 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
| nimbleron wrote: |
| fjb_saper wrote: |
| Ideally and to have redundancy, app1 should connect to both QM1 and QM2 and service the queue. The same way app2 should connect to both QM1 and QM2 and service the queue. This way if one app dies the other will pick up the messages... |
A solution pattern I try to follow is to not solve a problem that is solved in some vendor application or application component. So in this case, I'm first looking for IBM WMQ to solve this problem for me.
If WMQ does not solve the problem then things get ugly. Consider 5 Queue Managers and 5 Apps with each App needing to have 5 connections, one to each QMGR. That's unruly.
Thanks for the information though. |
Why each to 5? How about each to 2 or max 3?
Just round robbin wise.
App1 to qm1 and qm2
App2 to qm2 and qm3 .... and so on...
As noted by my esteemed colleague have a look at sample amqsclm
http://www-01.ibm.com/support/knowledgecenter/SSFKSJ_8.0.0/com.ibm.mq.dev.doc/q024620_.htm
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Thu May 07, 2015 3:39 pm Post subject: Re: Detecting Input Procs=0 and moving messages to another Q |
|
|
Jedi
Joined: 25 Mar 2003
Posts: 2494
Location: Melbourne, Australia
|
| nimbleron wrote: |
| ...In the situation where APP1 dies, and messages are left on that local cluster queue on QM1, is there any WMQ capabilty that detects the connection has died and moves those messages to QM2 so that they can be processed by APP2? |
The correct design solution is to have app monitoring that will detect APP1 down, and take action to alert or restart. Or run some other app that moves any marooned messages. Or put disable the queue or remove it from the MQ cluster until APP1 can be restarted (prevents MQ from sending any more messages to its LQ).
MQ's function is the deliver messages from A to B, not to make decisions about application operations.
_________________
Glenn |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu May 07, 2015 4:15 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9396
Location: US: west coast, almost. Otherwise, enroute.
|
The MQ solution to your 'consider this' is Shared Queues on MQ for z/OS.
Once a message is put to a shared queue, it will be consumed by an app on one of the available gmgrs.
_________________
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 |
|
|
| nimbleron |
| Posted: Thu May 07, 2015 5:41 pm Post subject: |
|
|
Newbie
Joined: 07 May 2015
Posts: 4
|
| Thank you all for your thoughtful responses. Good pointers and good stuff to ponder. |
|
| Back to top |
|
|
| nimbleron |
| Posted: Thu May 07, 2015 5:44 pm Post subject: |
|
|
Newbie
Joined: 07 May 2015
Posts: 4
|
| fjb_saper wrote: |
| nimbleron wrote: |
| fjb_saper wrote: |
| Ideally and to have redundancy, app1 should connect to both QM1 and QM2 and service the queue. The same way app2 should connect to both QM1 and QM2 and service the queue. This way if one app dies the other will pick up the messages... |
A solution pattern I try to follow is to not solve a problem that is solved in some vendor application or application component. So in this case, I'm first looking for IBM WMQ to solve this problem for me.
If WMQ does not solve the problem then things get ugly. Consider 5 Queue Managers and 5 Apps with each App needing to have 5 connections, one to each QMGR. That's unruly.
Thanks for the information though. |
Why each to 5? How about each to 2 or max 3?
Just round robbin wise.
App1 to qm1 and qm2
App2 to qm2 and qm3 .... and so on...
As noted by my esteemed colleague have a look at sample amqsclm
http://www-01.ibm.com/support/knowledgecenter/SSFKSJ_8.0.0/com.ibm.mq.dev.doc/q024620_.htm
Have fun |
Yes, yes, yes, that's it - thanks for the link.
And thanks to tczielke for reminding me that I'm not crazy afterall! |
|
| Back to top |
|
|
|
|
