| Author |
Message
|
| pbravic |
 Posted: Thu Apr 01, 2004 12:13 pm Post subject: Queues not getting Reflected in Cluster |
 |
|
Apprentice
Joined: 24 Nov 2003
Posts: 42
|
Hi
We are having 3 Qmanager each on separate box 2 on NT and one HP Unix. All the queue manager were on cluster. The 2 queue managers on the NT box are repository queuemangers.
(these are our QA boxes)
During our testing on QA we found that messages from NT queues are not going to the queues on unix. On investigation all the cluster queues of the unix queue manager which were in the cluster were not reflecting in the NT queue managers (cluster)
all the messages are in system.cluster.transmit.queue of the NT box
dis clusqmgr(*) on all the boxes show that all queuemangers are in cluster. the cluster queue the NT queue manager are getting reflected in the unix queue manager.
We suspended the cluster membership and rejoined the cluster still the unix cluster queues are not getting reflected
The system.cluster.repository.queue is having more than one messages (7).
The system.defl.clussdr channnel is in retrying state.
pls provide info to solve the above issue
Thanks and Regards
Ravi |
|
| Back to top |
|
 |
| mqonnet |
| Posted: Thu Apr 01, 2004 12:39 pm Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
To being with if your clussdr channel is in retry state, try and find out the reasons for it from mqerrlogs and the FFST's, if any were created. Unless you have a proper cluster setup, you cannot expect the subscription messages to be delivered to the participants.
Just because you can see a cluster does not mean the cluster is active and is correct. Status is cached. Since you rejoined, if all went on OK, you should see all the queues at all other queue managers.
Cheers
Kumar |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Apr 01, 2004 12:45 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Actually, I'm pretty sure the system.def.clussdr is used as a model channel, and should not even be started, much less be in retry. It should be "inactive" at all times.
So I don't think that's the issue.
But the fact that messages are still on the system.cluster.transmit.queue is at least a symptom of the problem.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| mqonnet |
| Posted: Thu Apr 01, 2004 1:06 pm Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
Jeff, i thought about that too. But the only reason i did not point that out was thinking that it is their naming convention. I know sounds odd, but you never know what customers do. But if it is a "system.def.clussdr", then yes, you are right. It is just a prototype def.
Cheers
Kumar |
|
| Back to top |
|
|
| pbravic |
| Posted: Thu Apr 01, 2004 1:28 pm Post subject: |
|
|
Apprentice
Joined: 24 Nov 2003
Posts: 42
|
thanks for the inputs
from the forum we are aware that SYSTEM.DEF.CLUSSDR doesn't have much significance. but we couldn't findout the cause of why queues are not getting reflected across the cluster
is there any way you suggest to address this pls let us know the same
thanks and regards
ravi |
|
| Back to top |
|
|
| pbravic |
| Posted: Thu Apr 01, 2004 1:32 pm Post subject: |
|
|
Apprentice
Joined: 24 Nov 2003
Posts: 42
|
thanks for the inputs
from the forum we are aware that SYSTEM.DEF.CLUSSDR doesn't have much significance. but we couldn't findout the cause of why queues are not getting reflected across the cluster
is there any way you suggest to address this pls let us know the same
thanks and regards
ravi |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Apr 01, 2004 1:38 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Look for errors relating to cluster channels in the logs on both the Unix systems and the NT system.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| mqonnet |
| Posted: Thu Apr 01, 2004 1:41 pm Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
After you have looked the errors up, you could verify that your cluster set is appropriate by checking the following.
1) dis chs(*) should show all the cluster channels in running state.
2) dis clusqmgr(*) should show all the participating qmgrs. Make sure you dont have any temp.*. That would mean that something went wrong and you need to figure that out and fix it.
3) dis qcluster(*) would then show the cluster queues that are published.
Cheers
Kumar |
|
| Back to top |
|
|
| pbravic |
| Posted: Thu Apr 01, 2004 7:06 pm Post subject: |
|
|
Apprentice
Joined: 24 Nov 2003
Posts: 42
|
checked the errors files
In the unix box
MQ9209: Connection to host 'yyyy' closed.
EXPLANATION:
An error occurred receiving data from 'yyyyover TCP/IP. The
connection to the remote host has unexpectedly terminated.
ACTION:
Tell the systems administrator.
In th nt box
AMQ9209: Connection to host 'hostname (yyyy)' closed.
EXPLANATION:
An error occurred receiving data from 'hostname (yyyy)' over TCP/IP.
The connection to the remote host has unexpectedly terminated.
ACTION:
Tell the systems administrator
all display command produces fine results
still the queues are not getting reflected |
|
| Back to top |
|
|
| mqonnet |
| Posted: Fri Apr 02, 2004 6:39 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
Well, few things dont quite really match in your descriptions.
In your initial post you said you had messages lying around on system system.cluster.repos.q. And in your latest post you say that you got error messages logged on unix and nt boxes saying that the connection to host was closed. Which would mean channels have some issues and may be they still are not running/retrying. But you say that all of the commands i posted last, dis chs(*), dis clusqmgr(*) and dis qcluster(*) return values as expected. If channels arent running, how can you have these commands executed and get good results.
I may be missing something here, or we dont have all the appropriate information to bind together everything.
Cheers
Kumar |
|
| Back to top |
|
|
| pbravic |
| Posted: Fri Apr 02, 2004 6:45 am Post subject: |
|
|
Apprentice
Joined: 24 Nov 2003
Posts: 42
|
Thanks Kumar
I missed to see the point, the time stamp of the errors were before we rejoined the cluster. sorry about that
all dis commands produces results needed
Thanks and Regards
Ravi |
|
| Back to top |
|
|
| mqonnet |
| Posted: Fri Apr 02, 2004 6:54 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
So, what is the problem now???
-You able to see the cluster queues defined on Unix on the Nt machines???
-Are the channels(cluster) up and running on all the qmgrs.
-Did you try and define a new cluster queue on unix box to see if the definition got propogated over to Nt boxes.
-Are the system.cluster* queues empty on unix box.
-Does ping channel on unix box work ok.
As a last resort i would probably do a refresh cluster, just to make sure all the participants are on the same page. Of course this being a test system and that you are out of options. At this time, it is not recommended though until the problem is traced out.
Cheers
Kumar |
|
| Back to top |
|
|
| pbravic |
| Posted: Fri Apr 02, 2004 7:58 am Post subject: |
|
|
Apprentice
Joined: 24 Nov 2003
Posts: 42
|
HI Kumar
The problem still remains the same
-You able to see the cluster queues defined on Unix on the Nt machines???
Ans: I could see the cluster queues defined in NT boxes which was created before this problem arises in the Unix QM. But, when I try to create a new cluster queue on NT box, its not reflected in the Unix box. But the same queue is available in all the NT QM.
Also, none of the Unix cluster queue is available in other QMs.
-Are the channels(cluster) up and running on all the qmgrs.
Ans: YES
-Did you try and define a new cluster queue on unix box to see if the definition got propogated over to Nt boxes.
Ans: No. Pls refer Question 1 above.
-Are the system.cluster* queues empty on unix box.
Ans: No. In the Unix QM,
The SYSTEM.CLUSTER.COMMAND.QUEUE holds 47 msgs.
SYSTEM.CLUSTER.REPOSITORY.QUEUE HOLDS 2 MSGS
SYSTEM.CLUSTER.TRANSMIT.QUEUE 0 MSG
In the NT1 Repos QM,
The SYSTEM.CLUSTER.COMMAND.QUEUE holds 0 msgs.
SYSTEM.CLUSTER.REPOSITORY.QUEUE HOLDS 155 MSGS
SYSTEM.CLUSTER.TRANSMIT.QUEUE 14 MSG
In the Unix QM,
The SYSTEM.CLUSTER.COMMAND.QUEUE holds 0 msgs.
SYSTEM.CLUSTER.REPOSITORY.QUEUE HOLDS 14 MSGS
SYSTEM.CLUSTER.TRANSMIT.QUEUE 1 MSG
We even tried REFRESH
-Does ping channel on unix box work ok.
Ans: Yes. I could ping.
Let me know if you could anything else. I tried refresh cluster on the UNIX box and NT1 box. But the problem still remains.
I am out of options now.
Thanks.
Ravi |
|
| Back to top |
|
|
| mqonnet |
| Posted: Fri Apr 02, 2004 8:45 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
Have responded to your other thread question that could be the problem why your subscription messages are not being propogated.
Also remember, cluster queues defined on repository queue manager would be propogated to non-repository queue managers only upon request. Hence cluster queues defined on NT boxes would be visible on Unix boxes only when need arises. Such as you trying to access this cluster queue hosted on Nt boxes connecting your app to Unix box.
Cheers
Kumar |
|
| Back to top |
|
|
| pbravic |
| Posted: Fri Apr 02, 2004 12:47 pm Post subject: |
|
|
Apprentice
Joined: 24 Nov 2003
Posts: 42
|
Hi kumar
we had found the route cause of the issue, after restarting the unix qm the cluster_sender channel got into retrying state, upon investigation we find that channel connection was not correct (may be due to an another test activity carried last week).
we find when we see the channel connection parameter through MQexplorer properties its showing the correct one (host_ip(1414)
but while checking for the status by clicking on the channel the connectioname is pointing to wrong machine (dummyhost_ip(1414))
using dis chs(*) shows the particular channel in retrying state and connention name is also (dummyhost_ip(1414))
we want to change the connection name of the channel (host_ip(1414))
we had follwed most of the suggestions in the forum but the connection still remains the same.
pls let us know the way to change the connection parameter of the cluster_sender channel
thanks and regards
ravi |
|
| Back to top |
|
|
|
|
