| Author |
Message
|
| charanR |
 Posted: Fri Jan 12, 2018 7:33 am Post subject: how do I failback when using queue manager groups in CCDT |
 |
|
Apprentice
Joined: 05 Oct 2017
Posts: 28
|
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 |
|
 |
| Vitor |
| Posted: Fri Jan 12, 2018 7:47 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, 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 |
|
|
| exerk |
| Posted: Fri Jan 12, 2018 8:34 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
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 |
|
|
| charanR |
| Posted: Fri Jan 12, 2018 9:08 am Post subject: |
|
|
Apprentice
Joined: 05 Oct 2017
Posts: 28
|
| 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 |
|
|
| fjb_saper |
| Posted: Fri Jan 12, 2018 11:22 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
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 |
|
|
| PaulClarke |
| Posted: Fri Jan 12, 2018 4:02 pm Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
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 |
|
|
| exerk |
| Posted: Sat Jan 13, 2018 6:33 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| 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 |
|
|
| PaulClarke |
| Posted: Sat Jan 13, 2018 7:31 am Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
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 |
|
|
| exerk |
| Posted: Sat Jan 13, 2018 7:34 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| 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 |
|
|
| PaulClarke |
| Posted: Sat Jan 13, 2018 7:36 am Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
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 |
|
|
| exerk |
| Posted: Sat Jan 13, 2018 8:40 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| 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 |
|
|
| charanR |
| Posted: Fri Jan 19, 2018 8:53 am Post subject: |
|
|
Apprentice
Joined: 05 Oct 2017
Posts: 28
|
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 |
|
|
| PaulClarke |
| Posted: Fri Jan 19, 2018 1:43 pm Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
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 |
|
|
| charanR |
| Posted: Fri Jan 19, 2018 1:54 pm Post subject: |
|
|
Apprentice
Joined: 05 Oct 2017
Posts: 28
|
| 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 |
|
|
| PaulClarke |
| Posted: Fri Jan 19, 2018 2:00 pm Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
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 |
|
|
|
|
