| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| problems with cluster qalias (rc=2082) |
« View previous topic :: View next topic » |
| Author |
Message
|
| tez_i |
 Posted: Wed Sep 24, 2008 2:30 am Post subject: problems with cluster qalias (rc=2082) |
 |
|
Novice
Joined: 03 Apr 2008
Posts: 12
|
I have a set up, where there are 3 qmgrs:
QM-SOURCE, QM-DMZ and QM-DEST
QM-SOURCE and QM-DMZ are in OUTER-CLUSTER
QM-DMZ and QM-DEST are in INNER-CLUSTER
There is Q.DEST, a clustered q, local to QM_DEST, and part of INNER-CLUSTER
There is Q.ALIAS on QM-DMZ, which is part of the OUTER-CLUSTER, the base q of which is Q.DEST in the INNER-CLUSTER
There is an app which uses JNDI bindings to QM-SOURCE, and puts a message to the Q.ALIAS - physically on QM-DMZ, but known to the OUTER-CLUSTER and QM-SOURCE. This is aparently 'successful' (as far as the app is concerned).
However, the cluster sender channel on QM-SOURCE then goes into retry, with the following error from AMQERR01.LOG on QM-DMZ :
> Program could not open queue manager object
> The attempt to open either the queue or queue manager
> object 'Q.ALIAS' on queue manager '' by user '' failed with
> reason code 2082.
From this, I gather that the app is 'successful' as far as the queue manager accepting the message to be put to the Q.ALIAS. ie the QM-SOURCE knows where to find the Q.ALIAS in the OUTER-CLUSTER, and the OUTER-CLUSTER is ok. (???)
But that QM-DMZ is rejecting the message, becuase it cannot resolve the base q for Q.ALIAS. (so there is a problem with q resolution on the INNER-CLUSTER ???)
HOWEVER, if I put a message directly to the QM-DMZ Q.ALIAS, the message is put sucessfully and seen on Q.DEST, so the alias definition and INNER-CLUSER are ok. (:-S ???)
The alias uses 'not fixed' bindings mode, which - as I understand it - should be correct in this situation. Also, as the error message states there is no destination queue manager being passed by QM-SOURCE that should not inflence the resolution of the q alias.
What am I missing? I fear I've been looking at this too long.... |
|
| Back to top |
|
 |
| ranganathan |
| Posted: Wed Sep 24, 2008 3:25 am Post subject: |
|
|
Centurion
Joined: 03 Jul 2008
Posts: 104
|
In your set up.. is INNER and OUTER CLUSTER are two different clusters ?!  if so, i could see that DMZ is part of both INNER and OUTER, did you create cluster channels for both FRs' ?
* Which is the Full Repository and partial repository ?
* Did you publish the base q to the cluster ?!
* What is the output of DIS CLUSQMGR(*) from the FR and PR?
* What is the output of DIS QCLUSTER (*) from the FR? are you able to see the Local Queue?
Finally, Ensure that the Cluster channels are running fine. |
|
| Back to top |
|
|
| tez_i |
| Posted: Wed Sep 24, 2008 4:40 am Post subject: |
|
|
Novice
Joined: 03 Apr 2008
Posts: 12
|
Thanks ranganathan!
Yes, DMZ is part of two overlapping clusters... and yes, I think this is where the problem lies, although I'm not sure why, becuase a similar set up works in our old v5.3 dev environment. Only difference being, this is an upgraded v6.0.2.4 dev environment. Point being, we're testing the upgrade!
As you can image, the description I gave was also rather simplified, but basicly:
DMZ is (one of) the FR for OUTER, and QM-SOURCE is a PR in this cluster
QM-DEST is (one of ) the FR for INNER, and DMZ is a PR in this cluster
I'm pretty sure the base queue is published: in MQExplorer it is showing as a QM-DEST cluster queue.....but any more pointers on double checking this would be appreciated.
(QM-SOURCE) -
>>> DIS CLUSQMGR shows all the queue managers in the OUTER cluster, inc itself, and the FR=DMZ
>>> DIS QCLUSTER shows the Q.ALIAS
>>> channel status shows TO.DMZ as retrying - error as stated. (2082)
this is the only cluster channel with a published status.
(QM-DMZ) -
>>> DIS CLUSQMGR shows all the queue managers in the OUTER cluster, inc QM-SOURCE and itself=FR as well as all the queue managers in the INNER cluster, inc itself and QM-DEST=FR (It lists itself twice, once for each cluster)
>>> DIS QCLUSTER shows the Q.ALIAS as part of OUTER and the base q as part of INNER, each with the expected values for clusqmgr respectively.
>>> channel status shows no active channels, but I can start TO.QM-DEST - ie the channel to the INNER FR - and it runs. The cluster receiver channel TO.QM-DMZ is inactive.
(QM-DEST)
>>> DIS CLUSQMGR shows all the queue managers in the INNER cluster, including itself=FR and DMZ
>>> DIS QCLUS shows the base queue
>>> channel status shows the TO.QM_DEST running, and no other channels running. The TO.QM_DMZ can be started and runs.
Does this sound about right? Anything else I should be checking? |
|
| Back to top |
|
|
| ranganathan |
| Posted: Thu Sep 25, 2008 3:33 am Post subject: |
|
|
Centurion
Joined: 03 Jul 2008
Posts: 104
|
Hi,
I guess the Repository information is not properly distributed because of the set up. I dont think you need a cluster for this scenario.. Instead you can have a Remote queue defined in DMZ and get the message to the destination queue manager..
But since you have had a running cluster make sure you follow the naming conventions for the cluster channels or else the cluster will go awry.
(Refer the clustering manual Advanced task-7)
Please find a similar post:
http://www.mqseries.net/phpBB2/viewtopic.php?t=44799&postdays=0&postorder=asc&start=0 |
|
| Back to top |
|
|
| sami.stormrage |
| Posted: Thu Sep 25, 2008 9:49 am Post subject: |
|
|
Disciple
Joined: 25 Jun 2008
Posts: 186
Location: Bangalore/Singapore
|
Your configuration won't work.
_________________
*forgetting everything  * |
|
| Back to top |
|
|
| tez_i |
| Posted: Mon Sep 29, 2008 7:35 am Post subject: Re: problems with cluster qalias (rc=2082) |
|
|
Novice
Joined: 03 Apr 2008
Posts: 12
|
Ok, the problem was mostly with this:
| tez_i wrote: |
if I put a message directly to the QM-DMZ Q.ALIAS, the message is put sucessfully and seen on Q.DEST
|
combined with this:
| tez_i wrote: |
| I fear I've been looking at this too long.... |
Because, in fact, the message wasn't being put on the correct target q after all. I have a number of queues with similar names, and there was a typo in the q alias configuration - naming the wrong base queue.
In effect - once the cluster was factored in - MQ was correct and the q-alias base q did not exist.
The local test worked fine, becuase the typo didn't affect it. Typical.
Sami, curious about your comment that the config won't work - becuase it does. (So long as the alias-base queue does actually exist). |
|
| Back to top |
|
|
| exerk |
| Posted: Mon Sep 29, 2008 11:10 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| sami.stormrage wrote: |
| Your configuration won't work. |
It's better to justify why/why not something will/will not work rather than make such a blank statement.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| sami.stormrage |
| Posted: Mon Sep 29, 2008 11:57 pm Post subject: |
|
|
Disciple
Joined: 25 Jun 2008
Posts: 186
Location: Bangalore/Singapore
|
the very basicx thing '-' is not allowed in a mqseries object name.. 
_________________
*forgetting everything * |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Sep 30, 2008 12:10 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| sami.stormrage wrote: |
| the very basicx thing '-' is not allowed in a mqseries object name.. |
| tez_i wrote: |
| ...HOWEVER, if I put a message directly to the QM-DMZ Q.ALIAS, the message is put sucessfully and seen on Q.DEST... |
In this case the poster is using '-' as punctuation - I doubt we're seeing the actual definitions...
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| 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
|
|
|
|
