| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Default cluster not available for connection |
« View previous topic :: View next topic » |
| Author |
Message
|
| gbenn |
 Posted: Fri Jul 19, 2002 11:28 am Post subject: Default cluster not available for connection |
 |
|
Novice
Joined: 19 Jul 2002
Posts: 12
Location: Ann Arbor, Michigan USA
|
I'm having a problem connecting 3 MQSeries servers running version 5.2 all on Windows 2000. So far I've setup a server with the default configuration acting as the repository for the cluster, DEFAULT_CLUSTER. Then I've setup two additional servers with the default settings and directed those via the Microsoft Networking names to the primary server with the repository.
I am able to send postcards between the two servers that are not repositories (I haven't checked between the repository server since it's located a further distance from me). I can share queues on the non-repository servers and see them on all 3 servers. But when I share a queue on the repository server it doesn't appear on the non-repository servers. During the install when I attempt to join that cluster I get the message: "The repository queue manager for cluster 'DEFAULT_CLUSTER' is not available for connection. Views showing cluster queues in this cluster may be incomplete (AMQ4515)"
I want to be able to put a message on the repository server however it's not working. All three servers are located on the same TCP/IP network and the MQSeries Explorer shows the QM's for each server but I can't get visibility of the queues on the reposity server existing on the DEFAULT_CLUSTER that all 3 servers reside on. Can anyone help me out!!??!?  |
|
| Back to top |
|
 |
| bduncan |
| Posted: Fri Jul 19, 2002 4:22 pm Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
I've seen this happen many times. It's usually a channel problem, or you didn't create all the MQ objects in the correct order. Each of your two queue managers should have a cluster sender and cluster receiver channel between itself and the repository machine. Check these and ensure that they are RUNNING. In runmqsc, use the 'dis clusqmgr(*)' command to see what each queue manager thinks is in the cluster. Do this on all three machines and make sure they are in sync. Check the logs for each queue manager. Usually if there was a problem communicating new MQ objects from the repository to other queue managers in the cluster, it will appear in the repository's log files. If any of the channels between the repository aren't RUNNING, use the PING CHANNEL command to see why they can't start.
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| gbenn |
| Posted: Mon Jul 22, 2002 4:59 am Post subject: |
|
|
Novice
Joined: 19 Jul 2002
Posts: 12
Location: Ann Arbor, Michigan USA
|
Brandon, thanks for the quick response. I took your advice and tested the connections and my results were similar on all 3 machines:
Microsoft(R) Windows DOS
(C)Copyright Microsoft Corp 1990-1999.
C:\>runmqsc
0784726, 5639-B43 (C) Copyright IBM Corp. 1994, 2000. ALL RIGHTS RESERVED.
Starting MQSeries Commands.
dis clusqmgr(*)
1 : dis clusqmgr(*)
AMQ8441: Display Cluster Queue Manager details.
CLUSQMGR(QM_gbenn_1496) CLUSTER(DEFAULT_CLUSTER)
CHANNEL(TO_QM_gbenn_1496)
AMQ8441: Display Cluster Queue Manager details.
CLUSQMGR(QM_s_mcare_42) CLUSTER(DEFAULT_CLUSTER)
CHANNEL(TO_QM_s_mcare_42)
:
PING CHANNEL(QM_gbenn_1496)
2 : PING CHANNEL(QM_gbenn_1496)
AMQ8227: Channel QM_GBENN_1496 not found.
PING CHANNEL(TO_QM_gbenn_42)
3 : PING CHANNEL(TO_QM_gbenn_42)
AMQ8227: Channel TO_QM_GBENN_42 not found.
PING CHANNEL(TO_QM_s_mcare_42)
4 : PING CHANNEL(TO_QM_s_mcare_42)
AMQ8227: Channel TO_QM_S_MCARE_42 not found.
:
end
5 : end
4 MQSC commands read.
No commands have a syntax error.
3 valid MQSC commands could not be processed.
C:\>
According to the MQServices application everything is running as it should (with the obvious exception of Trace). Any ideas? I'm going to go further examine the log file on the repository server here in a moment. |
|
| Back to top |
|
|
| gbenn |
| Posted: Mon Jul 22, 2002 5:54 am Post subject: |
|
|
Novice
Joined: 19 Jul 2002
Posts: 12
Location: Ann Arbor, Michigan USA
|
Additional Information:
I went to the machine hosting the repository and took a look at the error log file. There were several logs of it not being able to connect to one of the other servers but I think that was at a time where I had downed the system.
I attempted to PING the remote servers from the repository server and it gave me the error that it couldn't connect so then I STARTED the connection and made sure it was running and then it gave me the it's connected can't PING error/warning.
Now I'm back on the other server and at the bottom of the tree under "Clusters" and the cluster "DEFAULT_CLUSTER" the information is gives me shows the IP address, states it's REMOTE, and then under QUEUE MANAGER status it says UNAVAILABLE and under the CONNECTION STATUS it says Not Connected. Is this "Not Connected" a dynamic status that is only used with the Server and Client or Server and Server have issued an MQCONN/MQOPEN call or are my settings wrong?
I'm still seeing old remote queues being shared in my explorer that are no longer shared or in some cases test queues that no longer exist. Yet I can't see the two remote queues on the repository server that I am sharing. Obviously I'm new at this, and those training CD's from IBM are awful. Your assistance is greatly appreciated. |
|
| Back to top |
|
|
| bduncan |
| Posted: Mon Jul 22, 2002 7:22 am Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
I don't know if this is possible for you to do, but I would recommend deleting all three queue managers and starting over. If this is a production environment then I can understand why you can't do this, but if you are just using these machines to test out clustering, then we should start this over from the beginning. Why? Well, clustering (even on 5.2, though it is even more buggy on 5.1) can get into these funky states. That's why you see remote objects that aren't even there anymore, or no longer members of the cluster, etc. It also appears that your queue managers simply can't communicate with one another - hence the channel problems. So here's what I would do. Before blowing away all the queue managers, I would create traditional (static) channels between each queue manager. Just to see if they can communicate at all. If these channels work, then that means something is wrong with the cluster configuration. If they don't work, then you probably have a network configuration problem. Try this, and let me know. After that, we could try deleting the queue managers and then rebuilding the cluster using the steps in the Quick Beginnings Guide. I've found that if you don't follow these steps to the tee (especially in the right order even though intuitively you don't think the order matters) you can get a cluster up and running.
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
