| Author |
Message
|
| Zappa |
 Posted: Tue Oct 19, 2010 3:44 am Post subject: channel not stopping |
 |
|
Acolyte
Joined: 06 Oct 2005
Posts: 55
Location: UK
|
Hopefully this isn't a double post - I have searched but no matches I can see. I've reread the documentation.
I have a cluster sender channel with;
SHORTRTY(1)
SHORTTMR(5)
LONGRTY(1)
LONGTMR(1)
But when the QMGR at the remote end goes down the channel stays retrying for much longer than I expect. To me these settings would stop the channel after two retrys and 6 seconds.
It's probably a really stupid question but what have I missed?
Both MQ v6 on AIX. |
|
| Back to top |
|
 |
| zonko |
| Posted: Tue Oct 19, 2010 4:51 am Post subject: |
|
|
Voyager
Joined: 04 Nov 2009
Posts: 78
|
The values on a CLUSSDR are overridden by the same attributes on the CLUSRCVR.
Have you changed the CLUSRCVR as well? |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Oct 19, 2010 5:04 am Post subject: Re: channel not stopping |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Zappa wrote: |
| It's probably a really stupid question but what have I missed? |
This is possibly another stupid question and slightly off topic but why are these set so low?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Zappa |
| Posted: Tue Oct 19, 2010 5:19 am Post subject: |
|
|
Acolyte
Joined: 06 Oct 2005
Posts: 55
Location: UK
|
I hadn’t set the values on the receiver. I have now and the channel stops as I would expect with these values – Thank You.
I wouldn’t have considered the receiver to have been involved…
The values are this low because I don’t want too many MSGS stuck on the SCTQ as there are other QMGRS in the cluster sharing the same queue names and I want these to pick up the load when one isn’t available. – If there are other ways of doing this then please let me know. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Oct 19, 2010 5:29 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Zappa wrote: |
| The values are this low because I don’t want too many MSGS stuck on the SCTQ as there are other QMGRS in the cluster sharing the same queue names and I want these to pick up the load when one isn’t available. – If there are other ways of doing this then please let me know. |
Ah - using a WMQ cluster as an HA solution. A dubious idea often discussed in here.
Note that while your idea may work, you're paying for it in performance as the channels repeatedly stops and starts.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Oct 19, 2010 5:42 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| ...and I want these to pick up the load when one isn’t available |
Are you saying that if one of your cluster channels is in retry that no messages will flow out of the SCTQ to other qmgrs in the cluster?
_________________
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 |
|
|
| Zappa |
| Posted: Tue Oct 19, 2010 5:45 am Post subject: |
|
|
Acolyte
Joined: 06 Oct 2005
Posts: 55
Location: UK
|
| Quote: |
| you're paying for it in performance as the channels repeatedly stops and starts. |
Even if the communications are really good i.e. on the same network?
It is for HA and I might have to "tune" the values a bit because I really don’t want to be woken up in the middle of the night just to restart a channel.
But surely it's still a better HA option than paying out for idle standby servers what with WMQ and WMB license being so cheap or suffering performance hits when running too many components on one server. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Oct 19, 2010 5:51 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Zappa wrote: |
| But surely it's still a better HA option than paying out for idle standby servers what with WMQ and WMB license being so cheap |
That's the first time I've heard the license for either product described as "cheap"!
HA servers don't need to be idle. Look up "Active/Active" in Google.
| Zappa wrote: |
| Even if the communications are really good i.e. on the same network? |
Yes. The channel agents will stop & start, reconnecting to the queue manager and burning time & CPU while they do it. Connecting and disconnecting is the most expensive thing an application can do. This is why channels go inactive rather than stopping.
| Zappa wrote: |
| or suffering performance hits when running too many components on one server. |
WMQ clusters are really good at workload distribution. They suck at HA. This is because they're designed for one and not the other.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Zappa |
| Posted: Tue Oct 19, 2010 5:51 am Post subject: |
|
|
Acolyte
Joined: 06 Oct 2005
Posts: 55
Location: UK
|
If one QMGR in the cluster is down then yes we do get MSGS on the SCTQ destined for the absent one.
Is there another way of preventing this other than stopping the sender channel? |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Oct 19, 2010 6:01 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
I understand that messages will continue to arrive on the SCTQ.
I rephrase my question:
Are you saying that if ONE of your cluster channels is in RETRY that NO messages will be SENT out of the SCTQ to any of the other (remaining) qmgrs in the cluster?
_________________
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: Tue Oct 19, 2010 6:02 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
The best solution to HA is HA software, as has been discussed many times in here. If you want to use WMQ in this way then it can be made to work in a number of ways, in the same way you can use a 4-door sedan instead of a pick up truck. It doesn't work as well, and has some limitiations, but you can get by.
Of course, once your production application or database servers fall over you're toast unless you have some ingenious HA solution for them as well.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Zappa |
| Posted: Tue Oct 19, 2010 6:33 am Post subject: |
|
|
Acolyte
Joined: 06 Oct 2005
Posts: 55
Location: UK
|
I am indeed saying that the remaining qmgrs in the cluster do not pick up the msgs from the SCTQ that were destined for the downed QMGR.
I think that you’re implying that there is a way to configure this to not to happen and that they should be collecting without having to stop the retrying channel but is this by default? Please let me know as this happens to us by default. |
|
| Back to top |
|
|
| Zappa |
| Posted: Tue Oct 19, 2010 6:53 am Post subject: |
|
|
Acolyte
Joined: 06 Oct 2005
Posts: 55
Location: UK
|
Perhaps I need to rephrase my answer;
If we have two receiving QMGR’s and one goes down then only half the message are sent to the existing QMGR that’s running and half end up on the SCTQ. It’s the half the volume that I don’t want stranded on SCTQ.
The only way I know of preventing this is to stop the channel that is in a retrying state or have I missed something? |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Oct 19, 2010 7:07 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| the remaining qmgrs in the cluster do not pick up the msgs from the SCTQ that were destined for the downed QMGR. |
All this is working as designed and documented.
For clarity, receiving ends of channels do not pick up messages from the sending end transmission queue.
Sending end channels take messages from transmission queues, and send them to the qmgr whose name is determined (resolved) at MOOPEN/MQPUT/MQPUT1.
Cluster channels behave substantially the same as other point-to-point channels, namely: messages are sent to one downstream qmgr.
As pointed out is other replies, you are attempting a HA solution. WMQ clusters do not offer an HA solution.
That said, I do admire your ingenuity in setting retries low. As you discovered, this solution does not address messages already in the SCTQ; but will fix messages that are put after the channel stops (and the no-longer available cluster queue is taken out of the distribution equation.
_________________
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: Tue Oct 19, 2010 7:08 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Zappa wrote: |
| The only way I know of preventing this is to stop the channel that is in a retrying state or have I missed something? |
What I believe my most worthy associate is aluding to is that if you have 2 remote targets and the channel for one is in retry then the other channel (providing it's either inactive or running) should be selected as the target by the workload balancer - see here. Messages shouldn't sit on the SCTQ unless something else is at work. Like they made it in under the wire before even your highly agressive limits cut in.
What I am aluding to is how does your HA solution deal with the situation where the queue manager remains running but the application that reads messages from the queue (or the database that application relies on) crashes? The cluster will still direct message traffic to that queue manager.
I also repeat that this is costing you. Especially if you have intermittent traffic rather than a steady flow of messages.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
