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 1, 2  Next
how do I failback when using queue manager groups in CCDT View previous topic :: View next topic
Author Message
charanR
PostPosted: Fri Jan 12, 2018 7:33 am Post subject: how do I failback when using queue manager groups in CCDT Reply with quote

Novice

Joined: 05 Oct 2017
Posts: 18

Hello,

I'm able to do failover and see applications are able to reconnect but after doing failback, the application is still connected to the second queue manager. Is there any client connection configuration that I have to do so that application connects back to A ?. Here is my client connection from CCDT. A is my primary. Also, can anyone let me know how would I deal with stale messages left between the failovers in the first or second queue managers ? Any suggestions are appreciated.

Code:
AMQ8414: Display Channel details.
   CHANNEL(QMA101.A)                      CHLTYPE(CLNTCONN)
   AFFINITY(PREFERRED)                     ALTDATE(2017-12-29)
   ALTTIME(13.13.59)                       CERTLABL( )
   CLNTWGHT(0)                             COMPHDR(NONE)
   COMPMSG(NONE)                           CONNAME(10.1.2.3(1414))
   DEFRECON(YES)                           HBINT(300)                             
   KAINT(AUTO)                        MAXMSGL(4194304)
   QMNAME(QMA101)                          TRPTYPE(TCP)
   SHARECNV(10)
AMQ8414: Display Channel details.
   CHANNEL(QMA101.B)                      CHLTYPE(CLNTCONN)
   AFFINITY(NONE)                     ALTDATE(2017-12-29)
   ALTTIME(13.13.59)                       CERTLABL( )
   CLNTWGHT(1)                             COMPHDR(NONE)
   COMPMSG(NONE)                           CONNAME(10.1.2.4(1414))
   DEFRECON(YES)                           HBINT(300)                             
   KAINT(AUTO)                        MAXMSGL(4194304)
   QMNAME(QMA101)                          TRPTYPE(TCP)
   SHARECNV(10)


Last edited by charanR on Fri Jan 12, 2018 9:09 am; edited 1 time in total
Back to top
View user's profile Send private message
Vitor
PostPosted: Fri Jan 12, 2018 7:47 am Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 25114
Location: Ohio, USA

charanR wrote:
after doing failback, the application is still connected to the second queue manager


The CCDT has no concept of primary / secondary. If you want the application to reconnect to the primary queue manager, you need to make the secondary unavailable deliberately in the same way the primary became unavailable accidently.

charanR wrote:
Also, can anyone let me know how would I deal with stale messages left between the failovers in the first or second queue managers ?


Given you're failing back deliberately, that's part of your process.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
exerk
PostPosted: Fri Jan 12, 2018 8:34 am Post subject: Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 5898

Is that an MI queue manager, or do you really have two discrete queue managers in your estate but with the same name (implied by "...first or second queue managers...") ?
_________________
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
View user's profile Send private message
charanR
PostPosted: Fri Jan 12, 2018 9:08 am Post subject: Reply with quote

Novice

Joined: 05 Oct 2017
Posts: 18

exerk wrote:
Is that an MI queue manager, or do you really have two discrete queue managers in your estate but with the same name (implied by "...first or second queue managers...") ?


This is not a MI queue manager. just using queue manager groups using CCDT.

I thought AFFINITY(PREFERRED) does the failback if AFFINITY(NONE) is set on QMA101.B client channel. I guess I'm wrong on that.
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Fri Jan 12, 2018 11:22 am Post subject: Reply with quote

Grand Poobah

Joined: 18 Nov 2003
Posts: 19728
Location: LI,NY

charanR wrote:
exerk wrote:
Is that an MI queue manager, or do you really have two discrete queue managers in your estate but with the same name (implied by "...first or second queue managers...") ?


This is not a MI queue manager. just using queue manager groups using CCDT.

I thought AFFINITY(PREFERRED) does the failback if AFFINITY(NONE) is set on QMA101.B client channel. I guess I'm wrong on that.


You are wrong on that. The affinity comes only into play when making a connection or requesting a new connection. You then keep that connection until the app releases it, or it breaks. If the preferred connection becomes available, the app is not concerned because it already has a working connection.

Hope it helps
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
PaulClarke
PostPosted: Fri Jan 12, 2018 4:02 pm Post subject: Reply with quote

Guardian

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

I am not sure I agree with all the previous statements.

When you have multiple entries in your CCDT that could match your connection needs you can use the CCDT in two ways. One is in a predefined sequence....and the other is to randomly choose one of the choices.

This is controlled by whether you use CLNTWGHT or not. If the value is 0 then connections with be made in a predefined sequence. The sequence is controlled by the alphabetic ordering of the channel name. So, as in this case, QMA101.A will be attempted before QMA101.B.

The idea of AFFINITY is to try and get all the connections made on the same machine to connect to the same Queue Manager. Sometimes it doesn't matter in which case you would say NONE but sometimes it does matter in which case you say PREFERRED. For example, it is quite common for an application to make two connections, one for putting requests and another for getting the responses. The application would not work well if these two connections were to different Queue Managers so you would say 'PREFERRED' in this case.

So, I would imagine that if you change both CLNTWGHT values to 0 then you would get the primary and secondary ordering you want. In fact I would say that all entries in a CCDT with the same QMNAME should either have all zero or all non-zero values of CLNTWGHT.

Cheers,

Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com
Back to top
View user's profile Send private message Visit poster's website
exerk
PostPosted: Sat Jan 13, 2018 6:33 am Post subject: Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 5898

PaulClarke wrote:
I am not sure I agree with all the previous statements...

But it still won't "fail back" automatically, which is what the OP is after.
_________________
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
View user's profile Send private message
PaulClarke
PostPosted: Sat Jan 13, 2018 7:31 am Post subject: Reply with quote

Guardian

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

I think you are possibly putting words into their mouth a little there. You are the first person to mention the word 'automatic'.

Certainly there is no way of getting the client to 'automatically' throw away a perfectly good MQ connection in the hope that the client can connect to a 'better' Queue Manager. Destroying a connection (and connecting to another Queue Manager) would have all sorts of ramifications to the application such as transaction scope and marooned reply messages etc. It is not clear that you would really want the MQ Client to do this even if it could.

However, it is possible to configure your CCDT such that the MQ Client will always choose the 'first' available Queue Manager rather than sticking to the one it has already chosen and I thought that was the crux of the original question. If I misunderstood the issue then I apologise (it is early here).

Cheers,

Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com
Back to top
View user's profile Send private message Visit poster's website
exerk
PostPosted: Sat Jan 13, 2018 7:34 am Post subject: Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 5898

PaulClarke wrote:
I think you are possibly putting words into their mouth a little there. You are the first person to mention the word 'automatic'.

Implied by "...Is there any client connection configuration that I have to do so that application connects back to A ?..."
_________________
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
View user's profile Send private message
PaulClarke
PostPosted: Sat Jan 13, 2018 7:36 am Post subject: Reply with quote

Guardian

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

I don't agree that that sentence implies it needs to do it automatically. You could interpret the question multiple ways.

I don't really sere what point you are trying to make...surely it is up to the original poster to decide whether what I have said is useful or not.
_________________
Paul Clarke
MQGem Software
www.mqgem.com
Back to top
View user's profile Send private message Visit poster's website
exerk
PostPosted: Sat Jan 13, 2018 8:40 am Post subject: Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 5898

PaulClarke wrote:
I don't agree that that sentence implies it needs to do it automatically. You could interpret the question multiple ways.

I don't really sere what point you are trying to make...surely it is up to the original poster to decide whether what I have said is useful or not.

I'm not saying that what you have said is not useful to the OP, especially as you're the Oracle as far as I'm concerned, all I'm pointing out is that the implication is that the OP wants fail-over/fail-back. The title of the post is how do I failback when using queue manager groups in CCDT, and that to me (along with the previously quoted statement) is what suggests is that's what the OP wants.
_________________
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
View user's profile Send private message
charanR
PostPosted: Fri Jan 19, 2018 8:53 am Post subject: Reply with quote

Novice

Joined: 05 Oct 2017
Posts: 18

sorry, I have been away for sometime.

Thank you PaulClarke. I will try setting CLNTWGHT to zero and test it again.

Yes, I was kind of looking for an "automatic" way of failing back the connections. I understand that's not possible.
Back to top
View user's profile Send private message
PaulClarke
PostPosted: Fri Jan 19, 2018 1:43 pm Post subject: Reply with quote

Guardian

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

I think part of the problem would be for MQ to know when an appropriate time to throw away your perfectly good MQ connection would be.

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.

Cheers,

Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com
Back to top
View user's profile Send private message Visit poster's website
charanR
PostPosted: Fri Jan 19, 2018 1:54 pm Post subject: Reply with quote

Novice

Joined: 05 Oct 2017
Posts: 18

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.


we have like 100+ applications and each using their own way of connecting to MQ

from Oracle Service Bus, IBM commerce to inhouse built applications. I could probably ask in built apps to make this kind of a change but not sure on OSB/or the commerce platform.
I think my problem can be solved by MQ clustering but my company is not the one with deep pockets. I'm checking with IBM on the costs and see what they have to say"

Only other alternative I see is using VCS cluster or SUSE HAE.

SUSE is providing drbd support. I hope to setup something on these lines if not MQ clustering.
Back to top
View user's profile Send private message
PaulClarke
PostPosted: Fri Jan 19, 2018 2:00 pm Post subject: Reply with quote

Guardian

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

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 ?


Cheers,

Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:
Post new topicReply to topic Goto page 1, 2  Next Page 1 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.