| Author |
Message
|
| bduncan |
 Posted: Wed Jul 25, 2001 11:45 am Post subject: |
 |
|
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 |
|
 |
| NickB |
| Posted: Thu Jul 26, 2001 3:36 am Post subject: |
|
|
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 |
|
|
| bduncan |
| Posted: Thu Jul 26, 2001 9:21 am Post subject: |
|
|
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 |
|
|
| NickB |
| Posted: Thu Jul 26, 2001 11:23 pm Post subject: |
|
|
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 |
|
|
| kolban |
| Posted: Fri Jul 27, 2001 4:08 am Post subject: |
|
|
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 |
|
|
| zpat |
| Posted: Wed Jan 09, 2002 2:38 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5849
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 |
|
|
|
|
