Author |
Message
|
jcv |
Posted: Tue Jan 27, 2009 4:02 pm Post subject: |
|
|
 Chevalier
Joined: 07 May 2007 Posts: 411 Location: Zagreb
|
Is it conversion not supported (CCSID incompatibility) kind of problem? |
|
Back to top |
|
 |
fjb_saper |
Posted: Tue Jan 27, 2009 9:21 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Attempt at what the user induced error is: and it is quite grievous in a cluster environment: and yes it is an error between screen and keyboard.
The user defined the same cluster receiver channel name in 2 different queue managers in the cluster. So now when you try to send messages to qmgrA in the cluster the system does not know whether they have to go to qmgrA or qmgrB as they have the same channel name, and possibly even the same channel definition (same name and conname).
This is a very dangerous error and sends cluster command messages for A to B and vice versa...
So far the reaction has been:
- kill the repos process on the offended qmgr. clear the repos queue and cluster command queue.
- Fix the offending channel name on the offending qmgr.
- Refresh cluster on the offending qmgr.
- Restart the qmgr for which you killed the repos process.
- if needed run refresh cluster on this qmgr.
Thank god I only had it happen once or twice to me and I had just to deal with the aftermath and educate the junior admin.
This happens most often when you try to introduce another queue manager into the cluster to share load, but you did not delete/change the cluster receiver definition and you loaded the qmgr from the saveqmgr script from the other qmgr....
It is also accompanied with a marked slowness in cluster communications as a symptom.
Enjoy  _________________ MQ & Broker admin |
|
Back to top |
|
 |
Challenger |
Posted: Wed Jan 28, 2009 4:49 am Post subject: |
|
|
 Centurion
Joined: 31 Mar 2008 Posts: 115
|
fjb_saper
Another good attempt, and getting closer...you are correct that it is channel related, but wrong channel type.
All
That little hint above might just nudge you in the right direction now. |
|
Back to top |
|
 |
fjb_saper |
Posted: Wed Jan 28, 2009 5:03 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
You mean a cluster sender defined to match a cluster receiver only the cluster name/NL in the sender does not match the cluster name/NL on the cluster receiver?  _________________ MQ & Broker admin |
|
Back to top |
|
 |
Challenger |
Posted: Wed Jan 28, 2009 6:39 am Post subject: |
|
|
 Centurion
Joined: 31 Mar 2008 Posts: 115
|
fjb_saper
The CLUSSDR matched the name of the CLUSRCVR, and a NAMELIST was used in the channel definition...you're getting really warm here! |
|
Back to top |
|
 |
fjb_saper |
Posted: Wed Jan 28, 2009 6:54 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Challenger wrote: |
fjb_saper
The CLUSSDR matched the name of the CLUSRCVR, and a NAMELIST was used in the channel definition...you're getting really warm here! |
Did the namelist in the sender match the namelist in the receiver at the other end of the channel? Or did the receiver just have the clustername populated?
Did you have 2 different receiver channels defined on the same box for the same cluster?  _________________ MQ & Broker admin |
|
Back to top |
|
 |
mqjeff |
Posted: Wed Jan 28, 2009 6:58 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
fjb_saper wrote: |
Did you have 2 different receiver channels defined on the same box for the same cluster?  |
That's perfectly legal. |
|
Back to top |
|
 |
fjb_saper |
Posted: Wed Jan 28, 2009 7:02 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
mqjeff wrote: |
fjb_saper wrote: |
Did you have 2 different receiver channels defined on the same box for the same cluster?  |
That's perfectly legal. |
And how does the sender on qmgr X know which one to choose from, or is it a first to connect, first to be used basis?
And sorry I should have been specific and said cluster receivers :curious: _________________ MQ & Broker admin |
|
Back to top |
|
 |
mqjeff |
Posted: Wed Jan 28, 2009 7:06 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
Cluster Sender channels are automatically defined based on the information in the repository about Cluster Receiver channels.
Multiple CLUSRCVR channels for the same qmgr in the same cluster will result in multiple instances of the same queuemgr being shared in the cluster, and cluster workload balancing will occur across all of the CLUSRCVRs. |
|
Back to top |
|
 |
Challenger |
Posted: Wed Jan 28, 2009 7:34 am Post subject: |
|
|
 Centurion
Joined: 31 Mar 2008 Posts: 115
|
fjb_saper
Entries in the NAMELIST on each queue manager matched the cluster name. Additionally, all queue managers have only one CLUSRCVR.
All
A question: With a dearth of documentation, how easy do you think it is to identify FR's for a particular cluster? |
|
Back to top |
|
 |
fjb_saper |
Posted: Wed Jan 28, 2009 7:57 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Challenger wrote: |
fjb_saper
Entries in the NAMELIST on each queue manager matched the cluster name. Additionally, all queue managers have only one CLUSRCVR.
All
A question: With a dearth of documentation, how easy do you think it is to identify FR's for a particular cluster? |
Quite easy for the last part and the assumption here is that all FR's are correctly interconnected...
Get to any qmgr in the cluster and find the corresponding FR...
on any FR run
Code: |
dis clusqmgr(*) where (qmtype eq repos) |
You could run it on a partial repository but I don't know what the response would be if you have more than 2 FRs _________________ MQ & Broker admin |
|
Back to top |
|
 |
Challenger |
Posted: Wed Jan 28, 2009 8:38 am Post subject: |
|
|
 Centurion
Joined: 31 Mar 2008 Posts: 115
|
All queue manager may have only one CLUSRCVR but have a number of CLUSSDR's - dependent of course on the number of clusters they're in. The major issue here is that, as stated, a queue manager can be in a number of clusters and be FR for some, and PR in others.
Picture a queue manager that has a 'channel namelist' for its CLUSRCVR channel, and a 'repository namelist' for all the clusters it's an FR for...not forgetting these are (or were at the time) V5.3. |
|
Back to top |
|
 |
PeterPotkay |
Posted: Wed Jan 28, 2009 8:50 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
A QM can have multiple CLUSRCVRs. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
Challenger |
Posted: Wed Jan 28, 2009 11:00 am Post subject: |
|
|
 Centurion
Joined: 31 Mar 2008 Posts: 115
|
PeterPotkay wrote: |
A QM can have multiple CLUSRCVRs. |
Agreed, but these queue managers had just one - sometimes namelists are not a good thing. |
|
Back to top |
|
 |
jcv |
Posted: Wed Jan 28, 2009 4:46 pm Post subject: |
|
|
 Chevalier
Joined: 07 May 2007 Posts: 411 Location: Zagreb
|
If some cluster channel misconfiguration may cause Repository manager to end abnormally with RC xecS_E_MEM_SET_NOT_FOUND in v6 or 7, someone should definitely open an PMR and request the fix, at least to enhance the error report for that case. Because, no matter what user did, xecS_E_MEM_SET_NOT_FOUND doesn't tell much how to fix the problem, when you find that in your error log. If that applies only to v5.3, then it has already been recognized as an internal bug and fixed in newer versions. Probably it's not causing abnormal termination anymore. I mean, channel misconfiguration is user-induced problem, but bad error handling is not. Do you know how would Repository manager react to same misconfiguration in newer versions? |
|
Back to top |
|
 |
|