ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » Clustering » FORCEREMOVE does not FORCEREMOVE: why?

Post new topic  Reply to topic Goto page 1, 2  Next
 FORCEREMOVE does not FORCEREMOVE: why? « View previous topic :: View next topic » 
Author Message
svu
PostPosted: Tue May 31, 2011 12:24 am    Post subject: FORCEREMOVE does not FORCEREMOVE: why? Reply with quote

Voyager

Joined: 30 Jan 2006
Posts: 99

Hi all

It so happened (for some reasons which are out of scope) that one QM has to be forceremoved from the cluster. But usual RESET CLUSTER command does not work. The command is "accepted" - but the QM record still stays on the FR, according to DISPLAY CLUSQMGR (and MQ Explorer). I tried both QMNAME and QMID, tried QUEUES(YES) and (NO) (even though there were no clustered queues on that QM last time it was available). Of course, REFRESH CLUSTER was attempted as well (I know it is usually not needed - but just in case...)

The cluster transmission and command queues are empty. The cluster looks reasonably healthy otherwise. What can be wrong?

The WMQ version is 7.0.1.3, if it makes any difference.

Thanks
Back to top
View user's profile Send private message
exerk
PostPosted: Tue May 31, 2011 1:42 am    Post subject: Re: FORCEREMOVE does not FORCEREMOVE: why? Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 6339

svu wrote:
...The command is "accepted" - but the QM record still stays on the FR...

Both FRs?
_________________
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
View user's profile Send private message
svu
PostPosted: Tue May 31, 2011 1:47 am    Post subject: Reply with quote

Voyager

Joined: 30 Jan 2006
Posts: 99

The cluster is in the process of decomissioning. So only one FR is present ATM. Is that a problem?
Back to top
View user's profile Send private message
exerk
PostPosted: Tue May 31, 2011 2:01 am    Post subject: Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 6339

svu wrote:
The cluster is in the process of decomissioning. So only one FR is present ATM. Is that a problem?

Clusters should be decommissioned as they are built - FRs are always first to be created, so should be last to be 'deleted'. If all the queue managers are to be decommissioned too why bother with declustering? If they are not to be decommissioned, move on to other queue managers and leave that one to resolve until last.
_________________
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
View user's profile Send private message
svu
PostPosted: Tue May 31, 2011 2:32 am    Post subject: Reply with quote

Voyager

Joined: 30 Jan 2006
Posts: 99

Those ex-FR QMs became part of another larger cluster. But some QM records from the old cluster remain - and the old "zombie" cluster appears in WMQ Explorer, that does not look nice and clean.

Unfortunately the decomissioning did not went as planned, that is why 2nd FR got removed before the PR. Actually I tried to add the 2nd FR back - that did not resolve the issue with the sticky immortal PR.
Back to top
View user's profile Send private message
svu
PostPosted: Tue May 31, 2011 2:50 am    Post subject: Reply with quote

Voyager

Joined: 30 Jan 2006
Posts: 99

Anyway, adding 2nd FR back - did not resolve the issue
The interesting thing is that odd PR only exists on one FR - it does not get propagated to the 2nd FR (no autosender is created).
Other PR are visible on both.
Cluster senders/receivers work ok, on both FRs.
Back to top
View user's profile Send private message
Vitor
PostPosted: Tue May 31, 2011 5:05 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

svu wrote:
Anyway, adding 2nd FR back - did not resolve the issue


Because it's not the same FR - it has the same name but not the same id.

The PRs should remove themselves after however long it is.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
svu
PostPosted: Tue May 31, 2011 5:12 am    Post subject: Reply with quote

Voyager

Joined: 30 Jan 2006
Posts: 99

Well, if it is the same QM - will it get new QMID once readded as FR again?

Anyway, I cannot restore old QMID of the 2nd FR, can I? And I do not understand why is it not getting the info (about unkillable PR) from the 1st FR. And the original question stays - how could stupid me remove that stupid immortal PR?

BTW, on the 1st FR I do not see any autosender for the "previous reincarnation" of the 2nd FR.
Back to top
View user's profile Send private message
svu
PostPosted: Tue May 31, 2011 5:13 am    Post subject: Reply with quote

Voyager

Joined: 30 Jan 2006
Posts: 99

Vitor wrote:
The PRs should remove themselves after however long it is.
Well, RESET CLUSTER ... FORCEREMOVE should fix that, right? But it does not
Back to top
View user's profile Send private message
Vitor
PostPosted: Tue May 31, 2011 5:18 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

svu wrote:
Well, if it is the same QM - will it get new QMID once readded as FR again?


Oh - misread that - thought you recreated the old FR, not promoted it back to being an FR

svu wrote:
Anyway, I cannot restore old QMID of the 2nd FR, can I?




svu wrote:
And I do not understand why is it not getting the info (about unkillable PR) from the 1st FR.


Because for whatever reason the 1st FR doesn't believe in it.

svu wrote:
And the original question stays - how could stupid me remove that stupid immortal PR?


You probably can't. It sounds like the cluster is what I like to describe as "hosed". I think this is what happens when:

svu wrote:
Unfortunately the decomissioning did not went as planned


so you've not got the planned outcome.

A tangled cluster is not easy to fix. Burning everything to the ground and starting again may be the only option; consider building another cluster with the membership and topology you're looking for, then deleting the old stuff once it's working.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
svu
PostPosted: Tue May 31, 2011 5:37 am    Post subject: Reply with quote

Voyager

Joined: 30 Jan 2006
Posts: 99

Vitor wrote:
You probably can't. It sounds like the cluster is what I like to describe as "hosed". I think this is what happens when:

A tangled cluster is not easy to fix. Burning everything to the ground and starting again may be the only option; consider building another cluster with the membership and topology you're looking for, then deleting the old stuff once it's working.

You are killing me! "Not easy" != "impossible". Would you have any links about that?
Back to top
View user's profile Send private message
Vitor
PostPosted: Tue May 31, 2011 5:54 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

svu wrote:
You are killing me!


If I had $5 for every cluster that's gone down in flames due to a change not going as planned.....

If I had $5 for every cluster I've allowed to burn itself out while building it's replacement.....

Here's a question, and it's a question only you can answer. What's going to be faster, easier and more reliable going forwards. Beating your existing setup like a pinata until it gives in and displays the results you want, or accepting that when the decommissioning didn't go as planned it broke your setup & you need to build another one?

Only you can answer this, because only you know the size/complexity/polictics/business sensitivity of your setup.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
Vitor
PostPosted: Tue May 31, 2011 5:55 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

svu wrote:
Would you have any links about that?


Yes - the link you click on to raise a PMR. I suspect that's the only way you're going to recover this, if it's recoverable. You've followed the directions in the documentation and this has not helped. You've tried all the usual suggestions and this has not helped. It's either broken or you need detailed assistance.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
svu
PostPosted: Tue May 31, 2011 6:07 am    Post subject: Reply with quote

Voyager

Joined: 30 Jan 2006
Posts: 99

thanks

I just found - the channel is in InDoubt state. Perhaps that is why it could not be deleted. Any way to get it out of that state?
Back to top
View user's profile Send private message
bruce2359
PostPosted: Tue May 31, 2011 6:58 am    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.

svu wrote:
... the old "zombie" cluster appears in WMQ Explorer, that does not look nice and clean.


A bit late in the process, but I'd carefully weigh the relative importance of nice and clean before attempting your next project.

As to the other issue, namely how to remove a queue manager from a cluster, please refer to the WMQ Queue Manager Clusters manual and/or the InfoCenter - both describe in some detail exactly how to do this.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Goto page 1, 2  Next Page 1 of 2

MQSeries.net Forum Index » Clustering » FORCEREMOVE does not FORCEREMOVE: why?
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.