| Author |
Message
|
| topwoman |
 Posted: Tue Feb 03, 2004 11:26 pm Post subject: SYSTEM.DEF.CLUSSDR channel is RETRYING |
 |
|
Novice
Joined: 03 Feb 2004
Posts: 20
Location: Netherlands
|
This is a "Is my face red" sort of problem...
I was troubleshooting a "RETRYING" condition in a clustering environment, and inadvertently "START"ed the SYSTEM.DEF.CLUSSDR channel (I know, what a dumb thing to do).
No real harm done, except that this channel is now in a RETRYING status, and our monitoring program thinks we have a problem!
Short of modifying the monitoring program (which also reports "STOPPED" as a problem, so STOPping the channel is not a solution), is there some way I can reset the channel, so that it goes back to the INACTIVE status it should be in?
Need I add that this is happening in the Production environment, and the server is the cluster full repository, so rebuilding the queue manager is also not an option. |
|
| Back to top |
|
 |
| Michael Dag |
| Posted: Wed Feb 04, 2004 12:07 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
if you are on 5.3 you can...
| Code: |
STOP CHANNEL(channel_name ) [ MODE( QUIESCE | FORCE | TERMINATE ) ]
[ STATUS( STOPPED | INACTIVE) ]
[ QMNAME(qmname) ]
[ CONNAME(connection_name) ] |
Michael |
|
| Back to top |
|
|
| topwoman |
| Posted: Wed Feb 04, 2004 5:56 am Post subject: |
|
|
Novice
Joined: 03 Feb 2004
Posts: 20
Location: Netherlands
|
Michael,
Would that it were. Regrettably, we're running 5.2 at the moment. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Wed Feb 04, 2004 6:36 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
that's too bad...
alternatives:
1) leave it until your next service window, down the queuemanager and when it comes up again, the channel should be inactive.
2) create a fake queuemanager with listener, fill in the conname on the retrying clussdr and start it, put the timeout value on 60 seconds or so...
it will then time out... lastly remove the conname again...
I would go for option 1) especially when you know it's not causing a 'real' problem, just a 'red in face' situation 
Michael |
|
| Back to top |
|
|
| topwoman |
| Posted: Wed Feb 04, 2004 7:45 am Post subject: |
|
|
Novice
Joined: 03 Feb 2004
Posts: 20
Location: Netherlands
|
Thanks for your advice, MichaelDag.
We're opting for suggestion #1 -- we've agreed to a "scheduled outage" this weekend to "refresh the Middleware".  |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Feb 05, 2004 5:15 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
You could fix it right away by doing the following:
1. Create a new CLUSSNDR called "X.SYSTEM.DEFAULT.CLUSNDR". It will have all the attributes of the original SYSTEM.DEFAULT.CLUSNDR
2. Stop the retrying SYSTEM.DEFAULT.CLUSNDR
3. Delete SYSTEM.DEFAULT.CLUSNDR
4. Recreate SYSTEM.DEFAULT.CLUSNDR. You will have to specify the LIKE option to tell the QM how to create this new channel.
| Code: |
DEFINE CHANNEL(SYSTEM.DEFAULT.CLUSNDR) CHLTYPE(CLUSSDR) +
LIKE (X.SYSTEM.DEFAULT.CLUSNDR)
|
5. Delete X.SYSTEM.DEFAULT.CLUSNDR
I have done this on 5.3, and did not even need the LIKE paramter, so steps 1 and 5 were not needed. But 5.2 might be different, so try it both ways on a test system first.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Fri Feb 06, 2004 12:44 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
Creative!!! 
I like this solution a lot better then mine!
Michael |
|
| Back to top |
|
|
| topwoman |
| Posted: Fri Feb 06, 2004 1:20 am Post subject: |
|
|
Novice
Joined: 03 Feb 2004
Posts: 20
Location: Netherlands
|
So do I, Peter, Michael. Thanks for the suggestion.
We'll try it in test first.
I have to tell you that we did a restart of the queue manager yesterday (didn't want to wait until the weekend), and restarting did NOT reset the status to INACTIVE. It's still RETRYING. Go figure. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Feb 06, 2004 8:18 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Yes, I have seen this also. A channel that is RUNNING when the QM goes down is INACTIVE when the QM comes up, ready to be triggered.
But if the channel is RETRYING, then it is RETRYING when the QM comes back up. My guess is that MQ has no way of knowing exactly where in its BATCH it was when it went retrying, so there may be uncommitted messages. When it comes back up, it may have unfinished business in regards to the batch, so it goes right back to retrying to reconnect to the partner MCA, so it can find out what to do with the batch of messages - COMMIT or ROLLBACK. If there was no BATCH of messages, it still does this, just to make sure the other side agrees.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
