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 » General Discussion » Cluster behaviour with CLUSSDR channels in STOPPED state ...

Post new topic  Reply to topic
 Cluster behaviour with CLUSSDR channels in STOPPED state ... « View previous topic :: View next topic » 
Author Message
tkaravind
PostPosted: Thu Aug 23, 2007 10:39 am    Post subject: Cluster behaviour with CLUSSDR channels in STOPPED state ... Reply with quote

Acolyte

Joined: 24 Jul 2001
Posts: 60

Hi All,

I encountered the following behaviour with WMQ clusters :

We have two queue managers QM1 & QM2 as part of the same cluster.

Q1 is defined on both and included in this cluster ( clones ).
It is defined with Default Bind "NOT FIXED".

Normally another qmgr : QM3 sends msgs to both QM1 & 2 in a round-robin basis which is as expected.

However during a recent activity we were forced to Suspend QM1 from cluster and also STOPPED the cluster sender TO.QM1 on QM3 so as to ensure msgs went only to QM2. But by mistake the Q1 on QM2 was removed from cluster.

This caused QM3 to still try and send msgs to QM1 ( as it was only suspended). But msgs were stuck on System cluster xmit Q as the cluster sdr TO.QM1 was stopped.

We later included Q1 on QM2 as part of the same cluster and expected QM3 to retry the msgs on its System cluster xmit Q and send to QM2 , now that Q1 on it was clustered....

However this did NOT happen. We had to manually move the messages across.

Is this a normal behaviour of qmgr cluster ? Or is it happening because TO.QM1 was stopped and msg retry would have been automatic if the same was in RETRY state ?

This has caused big confusion. Any further info is highly appreciated.

Many thanks in advance.

Aravind
Back to top
View user's profile Send private message
bruce2359
PostPosted: Thu Aug 23, 2007 11:13 am    Post subject: Reply with quote

Guest




When you issue a STOP CHANNEL command, you must manually restart the channel.
Back to top
tkaravind
PostPosted: Thu Aug 23, 2007 11:18 am    Post subject: Reply with quote

Acolyte

Joined: 24 Jul 2001
Posts: 60

True. But my question was regarding the cluster behaviour itself - that it should try its best to deliver to an alternate location ( in this case QM2) if it cannot see a way to QM1 ( if TO.QM1 is STOPPED)
Back to top
View user's profile Send private message
jefflowrey
PostPosted: Thu Aug 23, 2007 11:26 am    Post subject: Reply with quote

Grand Poobah

Joined: 16 Oct 2002
Posts: 19981

http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/index.jsp?topic=/com.ibm.mq.csqzah.doc/qc10920_.htm

Quote:
the reallocation process is not driven if the channel has already failed

_________________
I am *not* the model of the modern major general.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Thu Aug 23, 2007 11:29 am    Post subject: Reply with quote

Guest




Quote:
Q1 is defined on both and included in this cluster ( clones ). It is defined with Default Bind "NOT FIXED".


Which BIND_ option did the programmer specify in the application?program?
BIND_FIXED?
BIND_NOT_FIXED?
BIND_AS_Q_DEF?
Back to top
tkaravind
PostPosted: Fri Aug 24, 2007 1:53 am    Post subject: Reply with quote

Acolyte

Joined: 24 Jul 2001
Posts: 60

Thanks Jeff. That link was very helpful.

However in this case how should one distinguish between a channel that has already failed and one that is "failing" ?

Can we assume that a channel that is in RETRY state is "failing" and STOPPED has already failed ?
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Fri Aug 24, 2007 4:52 am    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7722

that's my understanding.

If I'm going to stop a cluster channel to prevent messages from going to a QM, I stop the CLUSRCVR(s) on the QM I don't want anything going to. That way incoming channels are retrying, and messages stuck in the S.C.T.Q. get rerouted (unless they are hard coded to go to that one QM)
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
tkaravind
PostPosted: Fri Aug 24, 2007 6:20 am    Post subject: Reply with quote

Acolyte

Joined: 24 Jul 2001
Posts: 60

Thanks Peter. Yes...Stopping the CLUSRVCR channel would have been easier and the right thing to do as well.

Carrying this a bit forward, if queues on both queue managers ( QM1 & QM2) are defined as part of cluster correctly and if the cluster channel to one (QM1) is STOPPED ( on QM3) :

Is the cluster logic by default good enough to see this and route all the msgs from QM3 through to the queue manager ( QM2) for which the cluster sender can actually RUN ?

Or does this depend on some cluster settings ?
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Fri Aug 24, 2007 6:28 am    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY

Doesn't matter much if the messages have already gone through destination resolution. If the cluster found that the only viable destination queue is on QM1 the messages have been assigned to QM1 and will stay so.

Stopping the channel whether cluster receiver or sender will have little effect on existing messages once they have a destination qmgr assigned.

Now for NEWLY posted messages the algorythm should be able to determine the viable destinations and load balance between them.
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » General Discussion » Cluster behaviour with CLUSSDR channels in STOPPED state ...
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.