| Author |
Message
|
| issac |
 Posted: Thu Apr 14, 2011 12:59 am Post subject: How to connect to Multi-instance QMGR NOT with CCDT? |
 |
|
Disciple
Joined: 02 Oct 2008
Posts: 158
Location: Shanghai
|
Hello,
I've figured out how to do it with a CCDT file. But how to connect to a remote Multi-Instance QMGR with the hostname \ port \ channel configs?
I want the client to be able to auto-reconnect once the standby QMGR is activated.
We're trying not to make any change to our existing app and wish to make usage of the Multi-Instance feature. Please help, thanks!
_________________
Bazinga! |
|
| Back to top |
|
 |
| exerk |
| Posted: Thu Apr 14, 2011 1:09 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Why would you want to do this? Apart from the obvious conclusion that you may want non-WMQ V7.0.1 clients to connect to an MI queue manager?
Presumably you have an application that does not use a CCDT so unless the application can pick up changes to the hostname etc. dynamically (unlikely?) the only way I can see to achieve it is infrastructurally - create a DNS name and flip the values within it when fail-over occurs.
_________________
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 |
|
|
| issac |
| Posted: Thu Apr 14, 2011 1:44 am Post subject: |
|
|
Disciple
Joined: 02 Oct 2008
Posts: 158
Location: Shanghai
|
It's coded like this:
variables including hostname & port are received by parsing a properties file.
So we can change hostname & port values, but we're not likely to change to use CCDT. I'm wondering if IM supports connecting by hostname & port? Is CCDT the only way that auto-reconnection can be possible?
| Code: |
protected MQQueueConnection connectToQMGR(RuntimeRegistryDTO apDto) throws JMSException {
// setup JMS connection
MQQueueConnectionFactory cf = new MQQueueConnectionFactory();
cf.setHostName(apDto.hostname);
if(apDto.port >0)
cf.setPort(apDto.port);
else
DevLog.warn("PORT value is invalid and ignored for JMS config.");
cf.setTransportType(JMSC.MQJMS_TP_CLIENT_MQ_TCPIP);
cf.setQueueManager(apDto.qmgr);
cf.setChannel(apDto.channel);
cf.setCCSID(apDto.ccsid);
MQQueueConnection connection = (MQQueueConnection) cf.createQueueConnection();
return connection;
}
|
_________________
Bazinga! |
|
| Back to top |
|
|
| exerk |
| Posted: Thu Apr 14, 2011 1:48 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Auto-reconnection is something that needs to be coded into the client application - unless you're using WMQ V7.0 client code.
_________________
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 |
|
|
| issac |
| Posted: Thu Apr 14, 2011 1:57 am Post subject: |
|
|
Disciple
Joined: 02 Oct 2008
Posts: 158
Location: Shanghai
|
Would you please explain what's WMQ V7.0 client code please?
I can make changes to the code and switch to CCDT if I have to. But I just don't believe MI doesn't support to connect with a token consisted of hostnames and ports, like "MYHOST1(1414),MYHOST2(1414)". Nowhere documents CCDT is the only way, and nowhere provides any example other than CCDT.
On this page
http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp?topic=/com.ibm.mq.amqzag.doc/fa70156_.htm
it says the requirement to use auto-reconnection is :
JMS (JSE, and Java EE client container and managed containers)
I think my application qualifies JSE well, and it doesn't say "JMS connecting by CCDT"
_________________
Bazinga! |
|
| Back to top |
|
|
| exerk |
| Posted: Thu Apr 14, 2011 2:13 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
WMQ V7.0 client code is the 'new' code base provided with that version, the code base that contains all the bells-and-whistles such as full-duplex and client auto-reconnection (the latter was something that had to be handled by the client application).
What you have to consider is that by not using a CCDT is that you are losing the flexibility and automation of what you want to do. There is a world of difference between reconnection and a new connection.
_________________
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 |
|
|
| zpat |
| Posted: Thu Apr 14, 2011 2:18 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
You need to distinguish between the IBM auto-reconnect feature of WMQ v7 client (which is transparent to the application), and designing an application (for any version of MQ) which can re-connect to the same or to alternate hostnames if the connection breaks.
A CCDT just supplies values, it is possible to supply the same values via MQI parameters. IBM's auto-reconnect does not work with Java apps anyway (quite a restriction!). |
|
| Back to top |
|
|
| issac |
| Posted: Thu Apr 14, 2011 2:30 am Post subject: |
|
|
Disciple
Joined: 02 Oct 2008
Posts: 158
Location: Shanghai
|
Aha! I've figured it out. Connecting as an ordinary JSE applications is well supported. Perhaps InfoCenter writers thought it hardly worthwhile to create an example for.
The answer is here:
| Quote: |
The standby instance of a multi-instance queue manager is typically at a different network address to the active instance. Include the network addresses of both the instances in the client connection definition table (CCDT). Either provide a list of network addresses for the CONNAME parameter, or define multiple rows for the queue manager in the CCDT. |
_________________
Bazinga! |
|
| Back to top |
|
|
|
|
