| Author |
Message
|
| siliconfish |
 Posted: Fri Mar 28, 2003 5:42 pm Post subject: Urgent!! Please help. strange cluster situation |
 |
|
Master
Joined: 12 Aug 2002
Posts: 203
Location: USA
|
Hi All,
I have a cluster situation , I have ten frontend Queue Managers in a cluster with two repositories and two Queue Managers on the Hub which is connecting to a Queue Manager in the backend.
The ten frontend Queue Managers do not communicate with each other. The frontend Queue Managers sends a request to the Hub Queue manager through a cluster queue defined on the Hub Queue Managers to the backend Queue Manager. Backend Queue Manager sends the response back to the Hub which inturn sends it to the Cluster Reply Queue defined on the ten frontend Queue managers.
All the frontend Queue Managers define Cluster Sender Channel to the Repository and a Cluster Receiver Channel.
The concern here is I am seeing Auto Defined Cluster Sender Channels from one front end Queue Manager to one or more frontend Queue Managers, even though there isn't any communication between them. 
According to MQ Clustering Docs, the Auto Defined channels are defined whenever "needed", then why are these channels created and that too they are in running state. 
I would appreciate a quick answer.
Thanks
_________________
siliconfish |
|
| Back to top |
|
 |
| vennela |
| Posted: Fri Mar 28, 2003 7:54 pm Post subject: |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
| Quote: |
| The concern here is I am seeing Auto Defined Cluster Sender Channels from one front end Queue Manager to one or more frontend Queue Managers, even though there isn't any communication between them. |
If a qmgr is in a cluster and if it can talk to the repository, then it can talk to any of the amgrs in the cluster. That's a feature of the cluster.
Is it a problem for you if the qmgrs (your front end qmgrs) talk to each other. I don't know why the channels are in running state. But are the 10 cluster sender and 10 cluster receiver channels in running state on all the qmgrs (if not how many do you see in running state )?
-------
Venny |
|
| Back to top |
|
|
| siliconfish |
| Posted: Fri Mar 28, 2003 8:02 pm Post subject: |
|
|
Master
Joined: 12 Aug 2002
Posts: 203
Location: USA
|
If a qmgr is in a cluster and if it can talk to the repository, then it can talk to any of the amgrs in the cluster. That's a feature of the cluster.
I agree with the above, my question is if the Queue Manager defines Auto Cluster Sender channels to all the Queue Managers even though its not "needed" i mean there no communication between them?
Is it a problem for you if the qmgrs (your front end qmgrs) talk to each other.
(Not at all)
I don't know why the channels are in running state. But are the 10 cluster sender and 10 cluster receiver channels in running state on all the qmgrs (if not how many do you see in running state )?
yes all are in running state
_________________
siliconfish |
|
| Back to top |
|
|
| vennela |
| Posted: Fri Mar 28, 2003 11:09 pm Post subject: |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
What are the channel attributes?
But in first place why would they be started? You mean to say there is no reason for your front end queue managers to talk to each other.
See if there were any messages sent from those channels.
May be you should look at
LSTMSGTI( ) LSTMSGDA( )
Also what is DISCINT set to?
-------
Venny |
|
| Back to top |
|
|
| bduncan |
| Posted: Sat Mar 29, 2003 11:23 am Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
I think what you are seeing are automatic cluster sender channels being defined between each queue manager and the two repositories. From your original post, you say that you have two full respositories (as you should). You don't explicitly say which queue managers are the full repositories, but think about the following situation:
Let's say one of the full repositories is on the 'hub' machine. Another full repository is on one of the ten 'front end' queue managers. Now, on each front end queue manager, you manually define a cluster sender/receiver channel between it and the full repository on the hub. Now even though the front end queue managers won't communicate with each other, the moment you add a queue manager to a cluster, it automatically defines channels between it and all full repositories in the cluster. This means that you would see channels between it and the other front end queue manager which acts as a full repository.
I am guessing this is what is happening to you. If not, then yes, I am stumped as well...
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| siliconfish |
| Posted: Sat Mar 29, 2003 3:06 pm Post subject: |
|
|
Master
Joined: 12 Aug 2002
Posts: 203
Location: USA
|
Thanks for all the replies.
Both the Repositories are on the Hub.
None of the frontend Queue Managers are Repositories (Checked twice)
According to your response there shouldn't be any Auto Defined Cluster Channels between the Queue Managers which aren't Repositories unless "needed".
But I see that there are Auto Defined Cluster Channels and that some are in Running and Some are Inactive state.
And one more info our setup is working just fine I mean we are sending and receiving messages without any problem. This is just a strange situation which is bugging us.
_________________
siliconfish |
|
| Back to top |
|
|
| siliconfish |
| Posted: Sat Mar 29, 2003 3:11 pm Post subject: |
|
|
Master
Joined: 12 Aug 2002
Posts: 203
Location: USA
|
| vennela wrote: |
What are the channel attributes?
But in first place why would they be started? (I don't have any clue but they were Running)You mean to say there is no reason for your front end queue managers to talk to each other.
See if there were any messages sent from those channels.
May be you should look at
LSTMSGTI( ) LSTMSGDA( ) (They are null)
Also what is DISCINT set to? (6000 Which is the one set for SYSTEM.DEF.CLUSSDR)
-------
Venny |
_________________
siliconfish |
|
| Back to top |
|
|
|
|
