| Author |
Message
|
| kishorewps |
 Posted: Wed Dec 16, 2009 2:08 am Post subject: facing prob when Using CCDT for failover |
 |
|
Newbie
Joined: 16 Dec 2009
Posts: 5
|
HI
I am using MqExport binding with CCDT.
In my local i am having 2 QM (TEST1 and TEST2)
While creating QM i have created SVRCONN channel by checking the check box.
On TEST1 QM i have created
DEFINE CHANNEL(SYSTEM.DEF.SVRCONN) CHLTYPE(CLNTCONN) TRPTYPE(TCP)
CONNAME(localhost) QMNAME(TEST1)
DEFINE CHANNEL(BETA) CHLTYPE(CLNTCONN) TRPTYPE(TCP)
CONNAME(localhost) QMNAME(TEST2)
and
On TEST2 QM i Have created
DEFINE CHANNEL(BETA) CHLTYPE(SVRCONN) TRPTYPE(TCP)
after that When i am doing MQexport binding
in Request QM field i am giving TEST1*
My intention is when TESt1 is down the binding should pickup the messages from TEST2.
But its not working.The messages is not picing up and Both cases
like TEST1 is up and TEST1 is down.
Need help on this . |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed Dec 16, 2009 5:47 am Post subject: Re: facing prob when Using CCDT for failover |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| kishorewps wrote: |
| Need help on this . |
- Don't use SYSTEM.DEF.SVRCONN for application work. Define a channel ALPHA to go with BETA to connect to TEST1
- Connect to TEST* not TEST1*
- Search for the many discussions on using a CCDT for client failover in this forum using the search facility provided. You may find them useful and interesting.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| kishorewps |
| Posted: Fri Dec 18, 2009 3:48 am Post subject: |
|
|
Newbie
Joined: 16 Dec 2009
Posts: 5
|
thanks for the reply.
i am able achive the failover by *TEST1 in QM field. |
|
| Back to top |
|
|
| kishorewps |
| Posted: Fri Dec 18, 2009 5:16 am Post subject: |
|
|
Newbie
Joined: 16 Dec 2009
Posts: 5
|
I am trying MQImport with CCDT.
I am having able to put the messgae in TEST2 when TEST1 is down.
But when TEST1 is back into running state,Binding still posting the messages into TEST2 only. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Dec 18, 2009 5:44 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| kishorewps wrote: |
| i am able achive the failover by *TEST1 in QM field. |
I was close.... 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Dec 18, 2009 5:45 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| kishorewps wrote: |
| But when TEST1 is back into running state,Binding still posting the messages into TEST2 only. |
If TEST2 is still running, why is this surprising?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| kishorewps |
| Posted: Fri Dec 18, 2009 8:20 am Post subject: |
|
|
Newbie
Joined: 16 Dec 2009
Posts: 5
|
when TEST1 comes back it should put the messages to TEST1 right.
not to TEST2.
Thats my understanding on CCDT.
please let me know if i am wrong on this |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Fri Dec 18, 2009 8:40 am Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Dec 18, 2009 10:06 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| kishorewps wrote: |
| when TEST1 comes back it should put the messages to TEST1 right. |
| kishorewps wrote: |
| please let me know if i am wrong on this |
If TEST2 is still running and the connection is valid, why would messages suddenly start going to TEST1? How does the application/connection mechanism know TEST1 is back in this scenario?
The link you've been referred to contains much valuable information on this.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| kishorewps |
| Posted: Tue Dec 22, 2009 10:35 pm Post subject: |
|
|
Newbie
Joined: 16 Dec 2009
Posts: 5
|
sorry for the late response.
Thanks for the responses.
I am using MQ V6.0 and websphere Process server V6.2.
Let me explain what i have understand by previous reply.
MQ binding which i am using to connect to CCDT should be dynamic to chk every time which channel is running before posting the messgae. |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Dec 23, 2009 2:03 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| kishorewps wrote: |
| ...MQ binding which i am using to connect to CCDT should be dynamic to chk every time which channel is running before posting the message. |
No channel will be running until you invoke it, it's a SVRCONN; that type of channel is initiated by the client end and is reactive.
Put simply: using wild-cards, the first available queue manager will be used (determined by whether the channel starts) and if the connection to that queue manager drops then an alternative will be used, and the client application will stay 'bound' to that channel until such time as the channel closes or drops.
_________________
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: Wed Dec 23, 2009 6:02 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| kishorewps wrote: |
| MQ binding which i am using to connect to CCDT should be dynamic to chk every time which channel is running before posting the messgae. |
It should be, but it's not. The binding to the CCDT (to use your term) behaves as my most worthy associate explains. Once you've got a connection, you stick with that connection unless it drops. It's also impossible for the application to know which queue manager it got a connection to.
As the wildcard connections are tested in the order they appear in the CCDT you might think that you could always put the message to TEST1 (if available) by disconnecting and reconnecting before the put; in this way reestablishing your connection to the most preferred queue manager.
You'd be right. This would achieve what you're looking for. It would also chew up vast resources and reduce the performance of your application to that of a drugged snail dragging an anvil.
It's like getting weeds out of your garden. You could use a flamethrower; it would do what you wanted in that the weeds would be gone. It's not a good solution or a wise solution though.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Dec 23, 2009 7:44 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| It's also impossible for the application to know which queue manager it got a connection to. |
A few points:
When the application does an MQDISC, the next MQCONN will drive the search through the CCDT for an available qmgr.
For apps that put lots of messages, disconnecting after/before each put will increase response-time while the CCDT is searched and qmgr connection is tested.
The application could do an MQINQ to determine the queue manager name, then disconnect from TEST2 to re-drive the search through the CCDT.
Again, this is all working as designed. It just doesn't match your design to have TEST1 the primary destination for messages.
_________________
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 |
|
|
| mqjeff |
| Posted: Wed Dec 23, 2009 7:51 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| I'd thought there were client channel weighting numbers added in v7 to allow specifying a preference for a given qmgr. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Dec 23, 2009 7:57 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
CLNTWGHT on CLNTCONN channel def.
_________________
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 |
|
|
|
|
