Author |
Message
|
PeterPotkay |
Posted: Mon Dec 12, 2005 12:34 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
PeterPotkay wrote: |
Take the conname defs from that sender that is failing, log onto the sending server, and do a telnet to that other ip and port.
If the telnet fails, you got a network issue, or the listener is not up on the 2nd machine. |
_________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
ashritha |
Posted: Mon Dec 12, 2005 12:40 pm Post subject: |
|
|
Voyager
Joined: 25 Jul 2005 Posts: 85
|
Quote: |
If i create a simple sender and receiver channels both queuemanagers are able to send and receive from one another. The problem is only with one cluster-sender channel. |
I tried creating a simple sender and receiver channels on both machines and they start very fine.
I also pinged both the boxes from one other to check the network connection and they look fine. |
|
Back to top |
|
 |
PeterPotkay |
Posted: Mon Dec 12, 2005 1:02 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
OK, once you are 1000% positive the channel defs are as follows:
On Server1/QM1, the CLUSSNDR should have the conname/port # of Server2/QM2.
On Server1/QM1, the CLUSRCVR should have the conname/port # of Server1/QM1.
On Server2/QM2, the CLUSSNDR should have the conname/port # of Server1/QM1.
On Server2/QM2, the CLUSRCVR should have the conname/port # of Server2/QM2.
Make sure they are clustered!!!!
then issue REFRESH CLUSTER (*) REPOS(YES) on both QMs. If these QMs are Full repositories, change one to a partial, then run the command, change it back to a full, and do the same on the other one. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
ashritha |
Posted: Mon Dec 12, 2005 1:34 pm Post subject: |
|
|
Voyager
Joined: 25 Jul 2005 Posts: 85
|
Thanks Peter!!!
It worked.
I set no repository for QM1 which initially had full repository along with QM2. The sender channel started.
And then again I altered QM1 to have full repository. The sender channel is running like a charm.
Now, I have full repositories for both queue managers and all the channels are running perfectly.
Thanks so much once again to everyone. |
|
Back to top |
|
 |
EddieA |
Posted: Mon Dec 12, 2005 2:14 pm Post subject: |
|
|
 Jedi
Joined: 28 Jun 2001 Posts: 2453 Location: Los Angeles
|
ashritha wrote: |
My new channel definitions are now as follows:
Note: IP address of sys A is 10.11.141.120 and sys B is 10.11.50.113
CHANNEL DEFINITIONS OF SYSTEM NJSP01A:
DEFINE CHANNEL(NJSP01A.NJSP01B) CHLTYPE(CLUSSDR) TRPTYPE(TCP) CONNAME('10.11.50.113 (5555)') CLUSTER(CLUSTER_PROD)
DEFINE CHANNEL(NJSP01B.NJSP01A) CHLTYPE(CLUSRCVR) TRPTYPE(TCP) CONNAME('10.11.141.120 (3333)') CLUSTER(CLUSTER_PROD))
CHANNEL DEFINITIONS OF SYSTEM NJSP01B:
DEFINE CHANNEL(NJSP01B.NJSP01A) CHLTYPE(CLUSSDR) TRPTYPE(TCP) CONNAME('10.11.141.120 (3333)') CLUSTER(CLUSTER_PROD)
DEFINE CHANNEL(NJSP01A.NJSP01B) CHLTYPE(CLUSRCVR) TRPTYPE(TCP) CONNAME('10.11.50.113 (5555)') CLUSTER(CLUSTER_PROD)
I still run on the same problem. The only difference is that now the sender channel that was creating problem from the beginning is in initializing stage while previously that was in retrying stage.
The other sender channel works fine as it did with my previous piece of code. |
As an aside, I would consider your naming conventions here. The way you have this set up, when you add a new QM to this cluster, you would have to specify either "NJSP01B.NJSP01A" or "NJSP01A.NJSP01B" as it's CLUSSDR, even though the QM name isn't one of those. One of the "usual" conventions used is "TO.<QM Name>" for both CLUSSDR and CLUSRCVR.
Cheers, _________________ Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
Back to top |
|
 |
ashritha |
Posted: Tue Dec 13, 2005 6:58 am Post subject: |
|
|
Voyager
Joined: 25 Jul 2005 Posts: 85
|
Hi Eddie,
Thanks for the suggestions. I would surely follow them. The previous example was only a sample to understand and configure a clustered environment on windows before i start on my prod box.
When I get to the point of clustering on production environment I would surely consider your suggestion on naming standards.
Regards,
Ashritha |
|
Back to top |
|
 |
hguapluas |
Posted: Wed Dec 14, 2005 3:09 pm Post subject: |
|
|
Centurion
Joined: 05 Aug 2004 Posts: 105 Location: San Diego
|
Have you tried telneting from the server with the sender in retry/initialize mode to the target server on the appropriate port you configured for use? If you can get a connect, then you have a good path. If not, then you have a newtork issue that needs to be resolved.
It almost sounds as if you are having a route problem between the two servers. The network just doesn't know how to route traffic back. Check your infrastructure/route tables or put in a static route entry if needed (if you are using class C or B subnetted addresses).
Telnet is a simple check for connectivity at the network layer.
Cheers, |
|
Back to top |
|
 |
ashritha |
Posted: Thu Dec 15, 2005 12:43 pm Post subject: |
|
|
Voyager
Joined: 25 Jul 2005 Posts: 85
|
Thanks hguapluas!!!
It was not with the network but with the way i configured my queue managers to hold full repositories.
Now i worked around as directed in this forum and have a running cluster set up.
Thanks for your reply. Next, time I would surely put this in mind while troubleshooting. |
|
Back to top |
|
 |
mrlinux |
Posted: Tue Feb 28, 2006 7:22 am Post subject: |
|
|
 Grand Master
Joined: 14 Feb 2002 Posts: 1261 Location: Detroit,MI USA
|
Try removing the non repository qmgr from the cluster and
issue runmqsc command on the repositry box
reset cluster(CLUSTER_NAME) action(forceremove) qmname(QMGR_NAME)
Then add the box back into the cluster . (Make sure your channel defs are right) This should straighten it out. The repository holds hostname/port info _________________ Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
Back to top |
|
 |
|