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 IndexClusteringwar stories

Post new topicReply to topic
war stories View previous topic :: View next topic
Author Message
bduncan
PostPosted: Wed Jul 25, 2001 11:45 am Post subject: Reply with quote

Padawan

Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley

Anyone care to share some of their nightmares with clustering? I think the verdict is still out whether the advantages of clustering outweigh the drawbacks, but I think over time clustering will become more bullet-proofed. My biggest qualm is that the Queue Manager retains cluster object definitions for 90 days before removing them because of inactivity. But when objects get deleted or altered in the cluster, invariably we ended up with "ghost" definitions that no longer pointed to a valid object, but it still appeared in the partial and full repositories of the queue managers in our cluster. Waiting 90 days for these to go away was little comfort - same goes for IBM's assurances that the queue managers "knew" those objects were no longer valid and would never try to route messages there.


_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator
Back to top
View user's profile Send private message Visit poster's website AIM Address
NickB
PostPosted: Thu Jul 26, 2001 3:36 am Post subject: Reply with quote

Centurion

Joined: 20 May 2001
Posts: 107
Location: Zurich Financial Services

Been badly burnt with clustering in the past. This almost always occurs when you've made a simple mistake in the configuration and it is just impossible to back-out. IBM insist that clustering works perfectly and I agree that it does - provided you get all your definitions 100% correct and in the right sequence. It is just too unforgiving.

I have written a number of scripts to automate the tasks involved in getting queue managers to join clusters and this has made the probability of making mistakes much lower.

I have also compiled a list of hints & tips for problem solving which may be worthwhile sharing:

 Is the cluster repository manager process (amqrrmfa) running? If not it can be restarted by issuing the command amqrrmfa –m QmgrName

 Try clearing down the SYSTEM.CLUSTER.COMMAND.QUEUE

 You cannot create a remote queue definition to a clustered queue. For example if queue A defined on CH01DM1 is shared within a cluster so that UK01DM1 can see it, then you cannot create a remote queue definition on NB01 which points to queue A on UK01DM1.

 The queues SYSTEM.CLUSTER.TRANSMIT.QUEUE and SYSTEM.CLUSTER.REPOSITORY.QUEUE cannot be cleared down whilst the repository queue manager process is running.

 When defining a cluster receiver channel, be very careful when using the DNS name in the connection definition as you cannot guarantee that participating queue managers within the cluster also have access to that DNS definition. If you don't have global DNS, DO NOT use the DNS name in the connection.

 If a cluster sender channel goes in to retry state then it may be because it has got out of step – in this case reset the channel at either end to message number 1. Failing this, delete and recreate the channel definition and re-start it. If this still doesn’t work then re-start the queue manager! (last resort)

 If a cluster sender channel goes in to retry state, then check the queue manager error log. If the error log indicates that another cluster sender channel is in an “in-doubt” state, then even if that cluster sender channel no longer exists you should recreate the channel, resolve the in-doubt condition with a commit and then delete the channel.

 Automatically defined cluster sender channels are modelled on the cluster receiver channel “at the other end” and have a DEFTYPE of CLUSSDRA when issuing a DIS CLUSQMGR(*) DEFTYPE command.

 The undocumented command amqrfdm can be used to get information from the repository and cache.


I think its about time IBM put together a Redbook on clustering.
Back to top
View user's profile Send private message
bduncan
PostPosted: Thu Jul 26, 2001 9:21 am Post subject: Reply with quote

Padawan

Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley

Well, a few of us could always volunteer and write the redbook on clustering; I've noticed that many of the redbooks are actually written by third party authors. I wonder if IBM pays anything for this?


_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator
Back to top
View user's profile Send private message Visit poster's website AIM Address
NickB
PostPosted: Thu Jul 26, 2001 11:23 pm Post subject: Reply with quote

Centurion

Joined: 20 May 2001
Posts: 107
Location: Zurich Financial Services

Brandon

IBM arrange things called "residencies" where a number of professionals get together for a few weeks (e.g. at Hursley) and write a Redbook. IBM pay travelling and living expenses but no salary. I think you'd need a very understanding employer to take part in this scheme!
Back to top
View user's profile Send private message
kolban
PostPosted: Fri Jul 27, 2001 4:08 am Post subject: Reply with quote

Grand Master

Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA

I have been involved in a number of red-book residencies. On occasion, a customer has worked closely with IBM defining requirements for some key piece of function (to them) and are delighted to have their staff get early exposure to the function.

The red-books are usually written by a mix of IBMers (and sometimes customers). Some of the IBMers are field sales men or technical specialists and come from many disciplines. During the red-book writing phase, they almost always get access to the designers and developers of the topic being written about and come away being some of the best skilled on that area.

For more details, see

Red book residencies

[ This Message was edited by: kolban on 2001-07-27 05:09 ]
Back to top
View user's profile Send private message
zpat
PostPosted: Wed Jan 09, 2002 2:38 am Post subject: Reply with quote

Jedi Council

Joined: 19 May 2001
Posts: 5856
Location: UK

I've just been on a WMQI RedBook residency as a customer. We were in Raleigh so didn't really have access to the developers but it was still a useful and interesting experience.

[ This Message was edited by: zpat on 2002-01-09 02:41 ]
Back to top
View user's profile Send private message
Display posts from previous:
Post new topicReply to topic Page 1 of 1

MQSeries.net Forum IndexClusteringwar stories
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.