| Author |
Message
|
| shashivarungupta |
 Posted: Sun Mar 29, 2009 7:00 am Post subject: |
 |
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
| Vitor wrote: |
| shashivarungupta wrote: |
| In failure scenario it connects to secondary. |
And what happens to unprocessed messages on the primary?
|
Either connecting application got to send the request message for those reply messages again. Or if those are lying on the reply queue of the queue manager which is down, get those messages from that queue and put it on the other side (can't say it would be wise until appli. really requires those, because application might have got time out for those replies).
If application wants them then that can be done.
Do you have any other solution for that ? |
|
| Back to top |
|
 |
| shashivarungupta |
| Posted: Sun Mar 29, 2009 7:08 am Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
| Quote: |
Did you manage to work out if the messages were originating from one QM more than the other as suggested?
|
Not yet.
| Quote: |
If you just send a bunch of messages to the reply queue (Assuming correct MQOpen options) from the broker QM using something like RFHUTIL do you experience better workload management? |
I am using rfhutil and connecting and putting the messages on the primary gateway queue manager, as applications do. But the behavior is same, means not proper load sharing when getting the reply messages.
I'll try putting messages from the broker QM. I haven't given a shot on that. |
|
| Back to top |
|
|
| Vitor |
| Posted: Sun Mar 29, 2009 7:17 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| shashivarungupta wrote: |
| if those are lying on the reply queue of the queue manager which is down, get those messages from that queue and put it on the other side |
Now if the queue manager's down, how are you going to to achieve that?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| shashivarungupta |
| Posted: Sun Mar 29, 2009 7:30 am Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
| Vitor wrote: |
| shashivarungupta wrote: |
| if those are lying on the reply queue of the queue manager which is down, get those messages from that queue and put it on the other side |
Now if the queue manager's down, how are you going to to achieve that? |
I can't do that seriously until its up again. And when it'll be up then there would not be any sense to send those messages to secondary qmgr. |
|
| Back to top |
|
|
| Vitor |
| Posted: Sun Mar 29, 2009 8:49 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| shashivarungupta wrote: |
| Vitor wrote: |
| shashivarungupta wrote: |
| if those are lying on the reply queue of the queue manager which is down, get those messages from that queue and put it on the other side |
Now if the queue manager's down, how are you going to to achieve that? |
I can't do that seriously until its up again. And when it'll be up then there would not be any sense to send those messages to secondary qmgr. |
So how is it a failover solution when the processing of affected messages is reliant on the primary being fixed? Which, in the event of a hardware issue, could be an extended period?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| vol |
| Posted: Sun Mar 29, 2009 10:32 pm Post subject: |
|
|
Acolyte
Joined: 01 Feb 2009
Posts: 69
|
Msgs in a cluster which have multiple possible destinations are not workload balanced by putting application, but as a totality across all msgs put by the qmgr. If there is other traffic from the qmgrs which have received the msg and are putting the reply, then the distribution of those msgs will skew the distribution of the reply msgs.
An example:
qmgr C receives msgs from qmgrs A and B, and puts replies. If this is all that happens, the msgs will be evenly balanced. If qmgr C puts other msgs which go more to A than B, then the replies will go more to B than A. |
|
| Back to top |
|
|
| shashivarungupta |
| Posted: Sun Mar 29, 2009 11:00 pm Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
| Vitor wrote: |
| shashivarungupta wrote: |
| Vitor wrote: |
| shashivarungupta wrote: |
| if those are lying on the reply queue of the queue manager which is down, get those messages from that queue and put it on the other side |
Now if the queue manager's down, how are you going to to achieve that? |
I can't do that seriously until its up again. And when it'll be up then there would not be any sense to send those messages to secondary qmgr. |
So how is it a failover solution when the processing of affected messages is reliant on the primary being fixed? Which, in the event of a hardware issue, could be an extended period? |
As per Wikipedia:
Failover is the capability to switch over automatically to a redundant or standby computer server, system, or network upon the failure or abnormal termination of the previously active server, system, or network. Failover happens without human intervention and generally without warning, unlike switchover.
Failover in our mq cluster scenario will take care of the newly coming messages and will route them to the another active queue manager in the cluster. |
|
| Back to top |
|
|
| Vitor |
| Posted: Sun Mar 29, 2009 11:54 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| shashivarungupta wrote: |
As per Wikipedia:
Failover is the capability to switch over automatically to a redundant or standby computer server, system, or network upon the failure or abnormal termination of the previously active server, system, or network. Failover happens without human intervention and generally without warning, unlike switchover. |
I hope whoever's doing your technical audit and/or your senior management accept that definition, rather than the more generally used industry one which is more "service resumption" based! 
| shashivarungupta wrote: |
| Failover in our mq cluster scenario will take care of the newly coming messages and will route them to the another active queue manager in the cluster. |
This is entirely fine when the reply messages are non-time sensitive repsonses which can be duplicated (as you indicated above). It will be less fine in 6 months/12 months/1 year when someone decides to extend the messaging solution to include time sensitive updates, which can't sit on the queue of a downed queue manager until it comes back.
Wikipeida? 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| shashivarungupta |
| Posted: Mon Mar 30, 2009 1:01 am Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
[quote="Vitor"]
| Quote: |
| shashivarungupta wrote: |
| Failover in our mq cluster scenario will take care of the newly coming messages and will route them to the another active queue manager in the cluster. |
This is entirely fine when the reply messages are non-time sensitive repsonses which can be duplicated (as you indicated above). It will be less fine in 6 months/12 months/1 year when someone decides to extend the messaging solution to include time sensitive updates, which can't sit on the queue of a downed queue manager until it comes back.
|
Got it !!
Coming back to the earlier question "what could be done when messages are lying on the reply queue (unprocessed messages) when queue manager is down?"
What to do with those appls. which are time sensitive and waiting for the reply, and unfortunately queue manager goes down and there are unprocessed messages on the reply queue.
Shall I take your post an answer to that? |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Mar 30, 2009 1:15 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| shashivarungupta wrote: |
| Shall I take your post an answer to that? |
If you mean my previous comment that WMQ clustering is unsuitible for an HA/failover scenario then yes.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| exerk |
| Posted: Mon Mar 30, 2009 1:17 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| shashivarungupta wrote: |
| ...Coming back to the earlier question "what could be done when messages are lying on the reply queue (unprocessed messages) when queue manager is down?"... |
Nothing to those messages, but it is likely the applications may have sent another request to an available target.
| shashivarungupta wrote: |
| ...What to do with those appls. which are time sensitive and waiting for the reply, and unfortunately queue manager goes down and there are unprocessed messages on the reply queue... |
In which case the applications had better be able to reissue the request, deal with the duplicate reply, or possibly incomprehensible reply, that will be received when the 'down' queue manager is back 'up' again.
_________________
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: Mon Mar 30, 2009 1:39 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| exerk wrote: |
| In which case the applications had better be able to reissue the request, deal with the duplicate reply, or possibly incomprehensible reply, that will be received when the 'down' queue manager is back 'up' again. |
Which will be a little odd to any future developers, who are probably used to WMQ's "once and once only" delivery ethos. Here you have "one and once only, except you may get a duplicate sometimes". 
You can probably get round it in your specific scenario by ensuring that the expiry on the returning messages (I use this term to avoid igniting the reply/response debate again!) is set such that the message will expire before any failover/failback can be achieved. Of course, if it happens faster than you expect you'll still get duplicates. If the sending application can't/won't set expiry or sets it too high you'll get duplicates.
And if there's a backlog on the reading end you won't get messages at all.... 
My previous comments regarding time-sensitive persistent messages still apply, because obviously these can't expire. Nor can they be re-sent without a lot of complex business logic.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| shashivarungupta |
| Posted: Mon Mar 30, 2009 4:59 am Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
| WMBDEV1 wrote: |
Did you manage to work out if the messages were originating from one QM more than the other as suggested?
If you just send a bunch of messages to the reply queue (Assuming correct MQOpen options) from the broker QM using something like RFHUTIL do you experience better workload management? |
I tried putting messages on the broker queue managers (where request queue is defined).
Here are the scenarios:
1. When I put messages on the first broker qmgr, reply messages go to the secondary gateway queue manager's reply queue. Even when I set ReplyToQueueManager as First gateway queue manager.
2. When I put messages on the first broker qmgr, reply messages go to the secondary gateway queue manager's reply queue. When I set ReplyToQueueManager as Blank.
3. When I put messages on the second broker qmgr, reply messages go to the first gateway queue manager's reply queue. When I set ReplyToQueueManager as Blank.
4. When I put messages on the second broker qmgr, reply messages go to the first gateway queue manager's reply queue. When I set ReplyToQueueManager as secondary gateway queue manager.
5. When I put messages on the second broker qmgr, reply messages go to the first gateway queue manager's reply queue. When I set ReplyToQueueManager as first gateway queue manager.
These all scenarios I have tried.
I closed the queue all the times. |
|
| Back to top |
|
|
| exerk |
| Posted: Mon Mar 30, 2009 5:09 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
I think I need a picture...I'm thoroughly confused by your terminology, and what you have put in your last post - and I've had plenty of caffeine.
When you write "...Even when I set ReplyToQueue as First gateway queue manager...", do you mean you set the ReplyToQueueManager as the "...First gateway queue manager..." etc.?
_________________
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 |
|
|
| shashivarungupta |
| Posted: Mon Mar 30, 2009 5:11 am Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
| exerk wrote: |
I think I need a picture...I'm thoroughly confused by your terminology, and what you have put in your last post - and I've had plenty of caffeine.
When you write "...Even when I set ReplyToQueue as First gateway queue manager...", do you mean you set the ReplyToQueueManager as the "...First gateway queue manager..." etc.? |
Apology !!
I have corrected above post . |
|
| Back to top |
|
|
|
|
