| Author |
Message
|
| mvic |
 Posted: Thu May 27, 2010 3:46 pm Post subject: |
 |
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| PeterPotkay wrote: |
| There is nothing else in that presentation that talks about how a blank conname could work. In fact the only other examples (on page 15), do have connames filled in. |
A blank CLUSRCVR conname is valid. It works, because when the definition is sent to, and arrives at, the CLUSSDR it is known by the TCP/IP layers what the real IP address of the CLUSRCVR's sending interface is at that time.
Port 1414 is implicit, though. And, because of DHCP, the IP address can change.
See http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/topic/com.ibm.mq.csqzah.doc/qc11130_.htm |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu May 27, 2010 3:47 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| PeterPotkay wrote: |
| Well, I see what you are referring to on page 22, but I don't see how it could work. There is nothing else in that presentation that talks about how a blank conname could work. In fact the only other examples (on page 15), do have connames filled in. |
But it does say on page 20 explicitly to use a blank conname.
Given that it's qualified by "Use default port only" I would assume that it's picking up the local IP address by some dark magic & sticking 1414 on the end of it.
Given also that most sites consider 1414 a security risk it's not that helpful as advice goes. Or something I'd look at anything other than ascance.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mvic |
| Posted: Thu May 27, 2010 3:56 pm Post subject: Re: Multi-Instance Queue Managers |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu May 27, 2010 5:06 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
| mvic wrote: |
| PeterPotkay wrote: |
| There is nothing else in that presentation that talks about how a blank conname could work. In fact the only other examples (on page 15), do have connames filled in. |
A blank CLUSRCVR conname is valid. It works, because when the definition is sent to, and arrives at, the CLUSSDR it is known by the TCP/IP layers what the real IP address of the CLUSRCVR's sending interface is at that time.
Port 1414 is implicit, though. And, because of DHCP, the IP address can change.
See http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/topic/com.ibm.mq.csqzah.doc/qc11130_.htm |
Thanks mvic, I was not aware of that.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jeevan |
| Posted: Thu May 27, 2010 5:49 pm Post subject: |
|
|
Grand Master
Joined: 12 Nov 2005
Posts: 1432
|
| PeterPotkay wrote: |
| mvic wrote: |
| PeterPotkay wrote: |
| There is nothing else in that presentation that talks about how a blank conname could work. In fact the only other examples (on page 15), do have connames filled in. |
A blank CLUSRCVR conname is valid. It works, because when the definition is sent to, and arrives at, the CLUSSDR it is known by the TCP/IP layers what the real IP address of the CLUSRCVR's sending interface is at that time.
Port 1414 is implicit, though. And, because of DHCP, the IP address can change.
See http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/topic/com.ibm.mq.csqzah.doc/qc11130_.htm |
Thanks mvic, I was not aware of that. |
Peter,
would you please elaborate what you mean by saying:
| Quote: |
one Multi Instance QM has 2 Cluster Receiver channels:
TO.QM1.CLUSTERNAME.1 (with IP address of primary server)
TO.QM1.CLUSTERNAME.2 (with IP address of secondary server)
The whole cluster knows 2 ways into this QM, and one of the channels will always be valid. And the other would always be retrying - ack!
|
http://www.mqseries.net/phpBB2/viewtopic.php?t=51675
Having two cluster receiver channel may work but example in IBM doc says, have two entries in CONNAME separated by comma(,) and it is working in our case. |
|
| Back to top |
|
|
| jeevan |
| Posted: Thu May 27, 2010 8:41 pm Post subject: |
|
|
Grand Master
Joined: 12 Nov 2005
Posts: 1432
|
[quote="jeevan"]
| PeterPotkay wrote: |
| mvic wrote: |
| PeterPotkay wrote: |
| There is nothing else in that presentation that talks about how a blank conname could work. In fact the only other examples (on page 15), do have connames filled in. |
A blank CLUSRCVR conname is valid. It works, because when the definition is sent to, and arrives at, the CLUSSDR it is known by the TCP/IP layers what the real IP address of the CLUSRCVR's sending interface is at that time.
Port 1414 is implicit, though. And, because of DHCP, the IP address can change.
See http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/topic/com.ibm.mq.csqzah.doc/qc11130_.htm |
Thanks mvic, I was not aware of that. |
Peter,
would you please elaborate what you mean by saying:
| Quote: |
one Multi Instance QM has 2 Cluster Receiver channels:
TO.QM1.CLUSTERNAME.1 (with IP address of primary server)
TO.QM1.CLUSTERNAME.2 (with IP address of secondary server)
|
http://www.mqseries.net/phpBB2/viewtopic.php?t=51675
I did not understand the concept of two cluster receiver channels.
I mentioned my early post too that, CONNAME of the cluster receiver channel of the MI queue manager will have two entres but the autodefined cluster sender channel from FR to MI qmgr will have only one entriy in the CONNAME- the activeinstancehostname(port), When the active instance goes down and standby takes over, this will get updated accordingly.
Same will be the case with client connection channel. There will be two entries. when app can not make connection to the first conname, it tries to make with second/standby instance.
| Quote: |
Channel and client reconnection
Channel and client reconnection is an essential part of restoring message processing after a standby queue manager instance has become active.
Multi-instance queue manager instances are installed on servers with different network addresses. You need to configure WebSphere® MQ channels and clients with connection information for all queue manager instances. When a standby takes over, clients and channels are automatically reconnected to the newly active queue manager instance at the new network address. Automatic client reconnect is not supported by WebSphere MQ classes for Java.
The design is different to the way high availability environments such as HA-CMP provide a virtual IP address for the cluster and transfer the address to the active server. WebSphere MQ reconnection does not change or reroute IP addresses. It works by reconnecting using the network addresses you have defined in channel definitions and client connections. As an administrator, you need to define the network addresses in channel definitions and client connections to all instances of any multi-instance queue manager. The best way to configure network addresses to a multi-instance queue manager depends on the connection:
Queue manager channels
The CONNAME attribute of channels is a comma-separated list of connection names; for example, CONNAME('92.46.1.1(1415), 85.42.3.8(2423)'). The connections are tried in the order specified in the connection list until a connection is successfully established. If no connection is successful, the channel attempts to reconnect.
Cluster channels
Typically, no additional configuration is required to make multi-instance queue managers work in a cluster.
If a queue manager connects to a repository queue manager, the repository discovers the network address of the queue manager from the CONNAME of the CLUSRCVR channel at the queue manager. On TCPIP, the queue manager automatically sets the CONNAME if you omit it, or configure it to blanks. When a standby instance takes over, its IP address replaces the IP address of the previous active instance as the CONNAME.
If it is necessary, you can manually configure CONNAME with the list of network addresses of the queue manager instances.
Client connections
Client connections can use connection lists, or queue manager groups to select alternative connections. Client reconnection to a multi-instance queue manager is discussed in Automated client reconnection. Clients need to be compiled to run with WebSphere MQ Version 7.0.1 client libraries or better, and be connected to at least a Version 7.0.1 queue manager.
When failover occurs, reconnection takes some time. The standby queue manager has to complete its startup, and its clients and channels have to detect the connection failure, select the connection to the standby that has newly become active, and reconnect. If the failure takes place during a batch transfer on a message channel, the batch is rolled back and restarted. If the client is in the middle of an MQI call during the reconnection, it must tolerate an extended wait before the call completes.
|
|
|
| Back to top |
|
|
| exerk |
| Posted: Fri May 28, 2010 12:21 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
jeevan,
As you quoted from the manual "...The CONNAME attribute of channels is a comma-separated list of connection names; for example, CONNAME('92.46.1.1(1415), 85.42.3.8(2423)')...", is applicable for V7.0.1 and above ONLY. What happens to one of your V6.0 queue managers' CLUSSDR(s) to the MI queue manager when you fail over to the secondary node?
And the concept of two CLUSRCVR channels is easy - there are two channels available for the cluster! A bit like having class-of-service RCVR channels...
_________________
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 |
|
|
| J.D |
| Posted: Fri May 28, 2010 2:48 pm Post subject: |
|
|
Voyager
Joined: 18 Dec 2009
Posts: 92
Location: United States
|
| Is MI Queue Manager not useful if the Clients use WebSphere MQ classes for Java? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri May 28, 2010 8:03 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20767
Location: LI,NY
|
| J.D wrote: |
| Is MI Queue Manager not useful if the Clients use WebSphere MQ classes for Java? |
For it to be useful the clients will have to use the WebSphere MQ classes for Java Version 7.0.1.x ! 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mvic |
| Posted: Sat May 29, 2010 11:06 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
|
| Back to top |
|
|
| ramires |
| Posted: Sun May 30, 2010 11:19 am Post subject: |
|
|
Knight
Joined: 24 Jun 2001
Posts: 523
Location: Portugal - Lisboa
|
| mvic wrote: |
| Upgrading to 7.0.1 won't help much: it seems the WebSphere MQ classes for Java don't support automatic client reconnect (search down these pages for 'java') |
This is really confusing this MI QMs, reading the text is this APAR:
http://www-01.ibm.com/support/docview.wss?uid=swg1IC67225 IBM says: "This issue affects users of auto-reconnect feature of the WebSphere MQ v7.0.1 classes for Java Message Service (JMS)"
So there is a auto-reconnect feature for MQ classes for JMS but not for MQ classes for Java? |
|
| Back to top |
|
|
| jeevan |
| Posted: Sun May 30, 2010 11:44 am Post subject: |
|
|
Grand Master
Joined: 12 Nov 2005
Posts: 1432
|
| ramires wrote: |
| mvic wrote: |
| Upgrading to 7.0.1 won't help much: it seems the WebSphere MQ classes for Java don't support automatic client reconnect (search down these pages for 'java') |
This is really confusing this MI QMs, reading the text is this APAR:
http://www-01.ibm.com/support/docview.wss?uid=swg1IC67225 IBM says: "This issue affects users of auto-reconnect feature of the WebSphere MQ v7.0.1 classes for Java Message Service (JMS)"
So there is a auto-reconnect feature for MQ classes for JMS but not for MQ classes for Java? |
No. There is a problme/bug in auto-reconnect feature for MQ classes for JMS but not for MQ classes for Java. |
|
| Back to top |
|
|
| ramires |
| Posted: Sun May 30, 2010 12:10 pm Post subject: |
|
|
Knight
Joined: 24 Jun 2001
Posts: 523
Location: Portugal - Lisboa
|
| jeevan wrote: |
| No. There is a problme/bug in auto-reconnect feature for MQ classes for JMS but not for MQ classes for Java. |
Thanks jeevan, I understand the bug part, and reading the APAR text I conclude MQ classe for JMS support auto-reconnect feature, but according the documentation automatic client reconnect is not supported by MQ classes for Java.
Is this correct? |
|
| Back to top |
|
|
| jeevan |
| Posted: Sun May 30, 2010 12:16 pm Post subject: |
|
|
Grand Master
Joined: 12 Nov 2005
Posts: 1432
|
| ramires wrote: |
| jeevan wrote: |
| No. There is a problme/bug in auto-reconnect feature for MQ classes for JMS but not for MQ classes for Java. |
Thanks jeevan, I understand the bug part, and reading the APAR text I conclude MQ classe for JMS support auto-reconnect feature, but according the documentation automatic client reconnect is not supported by MQ classes for Java.
Is this correct? |
No. There is no any bug/problem in the auto-reconnect feature in MQ classes for Java.
Let me elaborate a bit. One of the requirements of MI qmgr is that the client reconnect automaticallyl. But there was /is bug in this feature for MQ classes for JMS but not in MQ classes for Java. Means, the MQ classes for Java works seamlessly.
Hope, I am clear. |
|
| Back to top |
|
|
| ramires |
| Posted: Sun May 30, 2010 12:20 pm Post subject: |
|
|
Knight
Joined: 24 Jun 2001
Posts: 523
Location: Portugal - Lisboa
|
|
| Back to top |
|
|
|
|
