| Author |
Message
|
| Sam Uppu |
 Posted: Tue Sep 22, 2009 7:28 am Post subject: Client failover setup with the channel table |
 |
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
Hi Guys,
I followed some of the links on this forum and MQClients v.7.0 manual to test this failover.
Lets say QM1 and QM2 are 2 qmgrs and contains the same set of queues on both QM1 and QM2.
There is a remote client app using MQClient in connecting QM1. If QM1 is not available for some reason it should automatically connect to QM2(the backup).
I defined the below mentioned channels on QM1 and QM2 to generate the CHLTAB file:
On QM1
ALPHA:
| Quote: |
dis chl(alpha)
2 : dis chl(alpha)
AMQ8414: Display Channel details.
CHANNEL(ALPHA) CHLTYPE(SVRCONN)
ALTDATE(2009-09-22) ALTTIME(09.30.0
COMPHDR(NONE) COMPMSG(NONE)
DESCR( ) HBINT(300)
KAINT(AUTO) MAXINST(999999999)
MAXINSTC(999999999) MAXMSGL(4194304)
MCAUSER( ) MONCHL(QMGR)
RCVDATA( ) RCVEXIT( )
SCYDATA( ) SCYEXIT( )
SENDDATA( ) SENDEXIT( )
SHARECNV(10) SSLCAUTH(REQUIRED)
SSLCIPH( ) SSLPEER( )
TRPTYPE(TCP)
AMQ8414: Display Channel details.
CHANNEL(ALPHA) CHLTYPE(CLNTCONN)
AFFINITY(PREFERRED) ALTDATE(2009-09-22)
ALTTIME(09.39.59) CLNTWGHT(0)
COMPHDR(NONE) COMPMSG(NONE)
CONNAME(host(1420)) DESCR( )
HBINT(300) KAINT(AUTO)
LOCLADDR( ) MAXMSGL(4194304)
MODENAME( ) PASSWORD( )
QMNAME(QM1) RCVDATA( )
RCVEXIT( ) SCYDATA( )
SCYEXIT( ) SENDDATA( )
SENDEXIT( ) SHARECNV(10)
SSLCIPH( ) SSLPEER( )
TPNAME( ) TRPTYPE(TCP)
USERID( )
dis chl(beta)
3 : dis chl(beta)
AMQ8414: Display Channel details.
CHANNEL(BETA) CHLTYPE(CLNTCONN)
AFFINITY(PREFERRED) ALTDATE(2009-09-22)
ALTTIME(09.40.11) CLNTWGHT(0)
COMPHDR(NONE) COMPMSG(NONE)
CONNAME(host(1421)) DESCR( )
HBINT(300) KAINT(AUTO)
LOCLADDR( ) MAXMSGL(4194304)
MODENAME( ) PASSWORD( )
QMNAME(QM1) RCVDATA( )
RCVEXIT( ) SCYDATA( )
SCYEXIT( ) SENDDATA( )
SENDEXIT( ) SHARECNV(10)
SSLCIPH( ) SSLPEER( )
TPNAME( ) TRPTYPE(TCP)
USERID( ) |
on QM2:
| Quote: |
dis chl(beta)
2 : dis chl(beta)
AMQ8414: Display Channel details.
CHANNEL(BETA) CHLTYPE(SVRCONN)
ALTDATE(2009-09-22) ALTTIME(09.14.17)
COMPHDR(NONE) COMPMSG(NONE)
DESCR(Server connection to WebSphere MQ client)
HBINT(300) KAINT(AUTO)
MAXINST(999999999) MAXINSTC(999999999)
MAXMSGL(4194304) MCAUSER( )
MONCHL(QMGR) RCVDATA( )
RCVEXIT( ) SCYDATA( )
SCYEXIT( ) SENDDATA( )
SENDEXIT( ) SHARECNV(10)
SSLCAUTH(REQUIRED) SSLCIPH( )
SSLPEER( ) TRPTYPE(TCP) |
Then I exported the channel table of QM1 onto the client machine.
The client app is providing the QMgr name as QM1 and is able to connect.
If I make the QMgr-QM1 down, the app is getting 2058 error. It is not failing over to QM2.
Any thoughts?.
Thanks. |
|
| Back to top |
|
 |
| exerk |
| Posted: Tue Sep 22, 2009 7:30 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
And how is the client to know that if it can't connect to the first queue manager that it should try the second? 
_________________
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 |
|
|
| Sam Uppu |
| Posted: Tue Sep 22, 2009 8:15 am Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
| exerk wrote: |
| And how is the client to know that if it can't connect to the first queue manager that it should try the second? |
The Client app would not know which QMgr is available. If one of the Qmgrs either QM1 or QM2 go down the client app wont know and the client has nothing to do with this approach.
When the client channels are defined with blank QMNAME and exported the channel table onto the client machine and the app is providing the blank QMgr Name...then the failover is working. Which is cool. The samething I am expecting when the app provides the Qmgrname. When the app provides teh QMgr name in the code, the clinet channels should be defined with the QMNAME in it. In this link it states that.
In the IBM's client manual: page 137 what I am trying to achive the client failover by providing the QMgr name in the client channel definitions.
Anything am I missing here?.
Thanks. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Sep 22, 2009 8:26 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
There are features in MQ v7.0.1 that are only available when you are running your code against the MQ v7.0.1 libraries.
In earlier versions you have to explicitly retry the connection when you receive a failure, in order for the next channel definition to be used. |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Tue Sep 22, 2009 8:36 am Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
I am running my MQServer 7.0.0.1 version and client running on 6.0.2.3 version. I will try with the 7.0.0.1 client libraries and see whether it makes any difference.
Thanks. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Sep 22, 2009 9:37 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Please note.
MQ v 7.0.0.1 is different than MQ v7.0.1.0.
Unless the *client* is running MQ v7.0.1.0 or later, you will have to write your code to retry the connection in the case of a failure. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Sep 22, 2009 9:51 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
AMQ8414: Display Channel details.
CHANNEL(ALPHA) CHLTYPE(CLNTCONN)
AFFINITY(PREFERRED) ALTDATE(2009-09-22)
ALTTIME(09.39.59) CLNTWGHT(0)
COMPHDR(NONE) COMPMSG(NONE)
CONNAME(host(1420)) DESCR( )
HBINT(300) KAINT(AUTO)
LOCLADDR( ) MAXMSGL(4194304)
MODENAME( ) PASSWORD( )
QMNAME(QM1) RCVDATA( )
RCVEXIT( ) SCYDATA( )
SCYEXIT( ) SENDDATA( )
SENDEXIT( ) SHARECNV(10)
SSLCIPH( ) SSLPEER( )
TPNAME( ) TRPTYPE(TCP)
USERID( )
dis chl(beta)
3 : dis chl(beta)
AMQ8414: Display Channel details.
CHANNEL(BETA) CHLTYPE(CLNTCONN)
AFFINITY(PREFERRED) ALTDATE(2009-09-22)
ALTTIME(09.40.11) CLNTWGHT(0)
COMPHDR(NONE) COMPMSG(NONE)
CONNAME(host(1421)) DESCR( )
HBINT(300) KAINT(AUTO)
LOCLADDR( ) MAXMSGL(4194304)
MODENAME( ) PASSWORD( )
QMNAME(QM1) RCVDATA( )
RCVEXIT( ) SCYDATA( )
SCYEXIT( ) SENDDATA( )
SENDEXIT( ) SHARECNV(10)
SSLCIPH( ) SSLPEER( )
TPNAME( ) TRPTYPE(TCP)
USERID( )
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Tue Sep 22, 2009 9:58 am Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
| mqjeff wrote: |
Please note.
MQ v 7.0.0.1 is different than MQ v7.0.1.0.
Unless the *client* is running MQ v7.0.1.0 or later, you will have to write your code to retry the connection in the case of a failure. |
I am not really sure whether it is a MQserver/client versioning issue. As this link is talking about the same issue back in 2004. In 2004 I believe we dont have either of MQversion 6 or 7. That means this functionality should work whichever version of MQ it is.
Comments please?. |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Tue Sep 22, 2009 10:02 am Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
Peter,
I think the Qmgr name should be the same in both client conn channels as per this doc(page 137).
and also this link
something wrong with me in perceiving?. |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Sep 22, 2009 10:16 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| Sam Uppu wrote: |
Peter,
I think the Qmgr name should be the same in both client conn channels as per this doc(page 137).
and also this link
something wrong with me in perceiving?. |
Yes. The 'old' method used was wild-card characters, as per THIS link (you may need to view the page source as in some browsers some of the text truncates).
_________________
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 |
|
|
| Sam Uppu |
| Posted: Tue Sep 22, 2009 10:19 am Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
Jeff,
I used the MQ 7.0.0.1 client libraries and seeing the same issue as MQ version 6.0.2.3 client libraries...getting 2058 when the QM1 is down.
Peter,
I created the ALPHA client channel with QMNAME(QM1) and BETA client channel with QMNAME(QM2) and exported the CHLTAB onto the client machine. When I make QM1 down, I am getting 2059 error.
any further thoughts?.
Thanks. |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Sep 22, 2009 10:32 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| mqjeff wrote: |
Please note.
MQ v 7.0.0.1 is different than MQ v7.0.1.0.
Unless the *client* is running MQ v7.0.1.0 or later, you will have to write your code to retry the connection in the case of a failure. |
Try actually reading the posts...
_________________
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 |
|
|
| PeterPotkay |
| Posted: Tue Sep 22, 2009 10:48 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
MQCONN with "QM*" as the QM name and you'll be fine.
Or define the channels with nothing in the QM name, and use nothing for the QM name on the MQCONN call.
In either of these 2 cases, you'll connect via the ALPHA channel first if QM1 is up and willing to take your connection, otherwise you'll go to QM2 via the BETA channel.
This is the classic behaviour up to and thru MQ 6.0. As others have said, MQ 7.0.0 gave you some new functionality, and MQ 7.0.1 gave you even more. Get the basic stuff working first.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Tue Sep 22, 2009 12:30 pm Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
| exerk wrote: |
| Sam Uppu wrote: |
Peter,
I think the Qmgr name should be the same in both client conn channels as per this doc(page 137).
and also this link
something wrong with me in perceiving?. |
Yes. The 'old' method used was wild-card characters, as per THIS link (you may need to view the page source as in some browsers some of the text truncates). |
Exerk, the link you provided is very valuable one...thanks.
| Quote: |
For example, if you have a group of queue managers – all with different names and hosted on machines with different IP addresses – you can use QMNAME in the definitions of the client channels to identify them as being part of a single group:
define channel(IN.SVRCONN1) chltype(CLNTCONN) conname(9.9.9.1) qmname(MYQMGROUP)
define channel(IN.SVRCONN2) chltype(CLNTCONN) conname(9.9.9.2) qmname(MYQMGROUP)
define channel(IN.SVRCONN3) chltype(CLNTCONN) conname(9.9.9.3) qmname(MYQMGROUP)
define channel(IN.SVRCONN4) chltype(CLNTCONN) conname(9.9.9.4) qmname(MYQMGROUP)
define channel(IN.SVRCONN5) chltype(CLNTCONN) conname(9.9.9.5) qmname(MYQMGROUP)
define channel(IN.SVRCONN6) chltype(CLNTCONN) conname(9.9.9.6) qmname(MYQMGROUP)If you want to connect to any queue manager in this group (regardless of what any of them are called), you can MQCONN to *MYQMGROUP. |
I defined both the client channels ALPHA and BETA with the QMNAME(QM). Exported the channel table onto the Client machine.
In the MQCONN call provided the QMgrName as *QM and the failover is working.
Thanks everyone for your valuable suggestions. |
|
| Back to top |
|
|
| broker_new |
| Posted: Fri Nov 06, 2009 12:12 pm Post subject: |
|
|
Yatiri
Joined: 30 Nov 2006
Posts: 614
Location: Washington DC
|
Hi Guys,
I did the same configuration for failing over the MQ client.
On the same host i created two queue managers.
DEVQM -->Port : 2000
TESTQM-->Port: 2001
I have created two client connection channels
define channel(TEST1.TO.DEVQM) chltype(CLNTCONN) conname(ipaddress) qmname(MYQMGROUP)
define channel(TEST1.TO.TESTQM) chltype(CLNTCONN) conname(ipaddress) qmname(MYQMGROUP)
I am receiving the following error.
Remote host 'IPAddress (1414)' not available, retry later.
The attempt to allocate a conversation using TCP/IP to host 'IP Address (1414)' was not successful. However the error may be a transitory one and it may be possible to successfully allocate a TCP/IP conversation later.
Try the connection again later. If the failure persists, record the error values and contact your systems administrator. The return code from TCP/IP is 10061 (X'274D'). The reason for the failure may be that this host cannot reach the destination host. It may also be possible that the listening program at host 'IP Address (1414)' was not running. If this is the case, perform the relevant operations to start the TCP/IP
i wonder where we specify the port numbers? |
|
| Back to top |
|
|
|
|
