ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum IndexGeneral IBM MQ Supporthow do I failback when using queue manager groups in CCDT

Post new topicReply to topic Goto page Previous  1, 2
how do I failback when using queue manager groups in CCDT View previous topic :: View next topic
Author Message
PeterPotkay
PostPosted: Fri Jan 19, 2018 5:30 pm Post subject: Reply with quote

Jedi Council

Joined: 15 May 2001
Posts: 7456

PaulClarke wrote:

It would be fairly trivial though to add this type of logic to your application. Something which knows when it is not connected to the ideal Queue Manager and that it doesn't have any outstanding replies. It could then re-issue the MQCONN periodically and if it does manage to connect to the 'ideal' Queue Manager would disconnect from the current connection.

This is how DataPower does it. You can't install MQ Client Channel Tables on the DataPower appliance, but they instead have the concept of Queue Manager Groups, with a Primary and Secondary connection you define. The appliance is always checking for the Primary MQ connection to come back up and when it does, it switches back.

On Appliance 1a, its QM Group has QueueManagerA as Primary QueueManagerB as secondary.

On Appliance 1b, its QM Group has QueueManagerB as Primary QueueManagerA as secondary.


When everything is fine, the MQ connections are even. If one of the queue managers becomes unavailable, all the connections from both appliances use the remaining queue manager. When the other queue manager comes back up, the DataPower appliance whose primary QM has that QM as primary swings all its connections back. Leaving everything nicely balanced.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Fri Jan 19, 2018 5:37 pm Post subject: Reply with quote

Jedi Council

Joined: 15 May 2001
Posts: 7456

PaulClarke wrote:
Perhaps it would be better to tell people what the actual problem you are trying to solve is rather than us debate about your chosen solution.

My first question two questions would perhaps be.....

  • Why do you need the concept of primary and secondary Queue Managers ? Why not just a set of Queue Managers all of which are equally valid to connect to ?

  • If you do connect to a Queue Manager why do you feel the need to fall back at all? Why not stick with the one you have ?



A rolling maintenance of the queue managers, restarting one then the other, would leave all the MQ Client connections on one of the queue managers and the other would have none. Now, that is not necessarily a problem if either queue manager is adequately sized to deal with all the workload. But perhaps performance is not ideal but good enough when you have an unplanned or planned outage of one of them, however when both QMs are up you'd rather have the workload evenly split again for the best performance.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
PaulClarke
PostPosted: Fri Jan 19, 2018 6:07 pm Post subject: Reply with quote

Guardian

Joined: 17 Nov 2005
Posts: 902
Location: New Zealand

Peter,

I am not sure whether you are agreeing with me or disagreeing. I am just trying to get to the crux of the requirement. Like you I tend to like my Queue Managers evenly loaded however the OP seems to indicate that they do indeed want all their connections going to a single Primary Queue Manager and only if there is a problem have them fail to a Secondary. Furthermore , at some later stage they would like them to fail back to the Primary.

If you don't have any affinity and the applications don't hold on to their connections for too long then it would seem that either model is possible depending on how you configure your CCDT. However, it does mean that either applications need to periodically disconnect and reconnect to see if there is a better choice or you would need an administrative kick to tell the applications that the system has been 'fixed' and that they should disconnect and reconnect to a 'better' Queue Manager. Of course that 'kick' could just be a STOP CONN(*) or STOP CHL(*) issued on the Queue Manager.
_________________
Paul Clarke
MQGem Software
www.mqgem.com
Back to top
View user's profile Send private message Visit poster's website
charanR
PostPosted: Mon Jan 22, 2018 6:28 am Post subject: Reply with quote

Novice

Joined: 05 Oct 2017
Posts: 18

PaulClarke wrote:


  • Why do you need the concept of primary and secondary Queue Managers ? Why not just a set of Queue Managers all of which are equally valid to connect to ?


I'm worried about load balancing the connections. With AFFINITY(PREFERRED) and CLNTWGHT set to 10 lets say for both, I need to test if I'm able to achieve both servers are load balanced in terms of cpu, memory etc.
PaulClarke wrote:


  • If you do connect to a Queue Manager why do you feel the need to fall back at all? Why not stick with the one you have ?


yup, there is no need to failback but just wondering if there is a way to it.
Back to top
View user's profile Send private message
Display posts from previous:
Post new topicReply to topic Goto page Previous  1, 2 Page 2 of 2

MQSeries.net Forum IndexGeneral IBM MQ Supporthow do I failback when using queue manager groups in CCDT
Jump to:



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
Protected by Anti-Spam ACP


Theme by Dustin Baccetti
Powered by phpBB 2001, 2002 phpBB Group

Copyright MQSeries.net. All rights reserved.