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 » Clustering slows down the process drastically

Post new topic  Reply to topic
 Clustering slows down the process drastically « View previous topic :: View next topic » 
Author Message
vennela
PostPosted: Fri Sep 06, 2002 3:46 am    Post subject: Clustering slows down the process drastically Reply with quote

Jedi Knight

Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India

I have this setup

A1 ,,,, A2 ,,, A3 ,,,, A4 ,,,, A5 ,,,, A6

,,,,,, AB1 ,,,,,, AB2

,,,,,, B1 ,,,,,,, B2 ,,,,,,, B3


A1, A2, A3, A4, A5, A6 and AB1, AB2 are in a cluster

B1, B2, B3, AB1, AB2 are in another cluster.

AB1 and AB2 are the repositories for both the clusters.

When an application is fired at B1, the final result is :
A total of 100 messages from A1 to A6 (the number of messages from each of them may vary) should reach B1 via AB1 and AB2.

Similarly if B2 fires, it gets the 100 messages from A1 to A6 via AB1 and AB2.

Now when AB1 is up and AB2 is down the messages reach B1 in 5 minutes.
When AB2 is up and AB1 is down the messages reach B1 in 5 minutes.

But when both AB1 and AB2 are up the messages take 45 minutes to reach B1.

Below is the snapshot of number of messages on XMITQ of AB1 and AB2 in the 45 minutes span.

AB1 -- AB2 -- Time
48 --- 47 ----- 5 mins (B1 got the other 3 messages)
49 --- 46 ----- 10 mins (B1 got none)
97 ----- 0 ------ 15 minutes (B1 got none)
47 ----- 48 ----- 17 minutes
47 ---- 0 ------ 18 minutes (B1 got 48 messages this time)
23 ----- 24 ------ 22 mins
0 ------ 47 ------ 28 mins
23 ---- 24 ------ 30 mins
0 ----- 24 ------- 33 mins
12 ---- 0 -------- 35 mins
0 ----- 12 ------ 37 mins
6 ----- 5 ------- 38 mins
3 ----- 0 -------- 40 mins
0 ----- 3 -------- 42 mins
1 ----- 0 ------- 43 mins
0 ----- 0 ------- 45 mins

I am unable to fathom why messages are flowing between AB1 and AB2.

My gut feeling is, since AB1, AB2 and B1 are in a cluster, the messages that are with AB1 are sent to AB2 and B1. But this theory can't explain all the cases.
Sometimes all the messages are sent from AB1 to AB2. Why?
Any clues why this is behaving this way. We will run the test again. But before that please suggest me if I have to watch out for anything. The network guys say they don't see anything wrong from their end.

---
Venny
Back to top
View user's profile Send private message Send e-mail Visit poster's website
bduncan
PostPosted: Fri Sep 06, 2002 9:07 am    Post subject: Reply with quote

Padawan

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

Venny,
Not sure if this is the problem, but I've never seen overlapping clusters where the two full repositories for both clusters are also the only queue managers shared between the clusters. Everytime I've ever implemented (or seen implemented) an overlapping cluster, you have 2 full repositories for cluster 1, and 2 different full repositories for cluster 2. Each of these sets of full repositories are only visible in their respective cluster. Then, whichever queue managers I need to be visible in both clusters, THOSE are the queue managers which I make members of both clusters.
_________________
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
abanks
PostPosted: Mon Sep 16, 2002 3:37 am    Post subject: Reply with quote

Newbie

Joined: 04 Apr 2002
Posts: 3

Have you defined a QMGR alais called B1 for B1 in AB1 and AB2?

eg. DEF QREMOTE(B1) RQMNAME(B1) RNAME(' ') CLUSTER(B)

If so, a message arriving in say AB1 would have a choice of the real B1 or its alias in AB2 as its next destination. On average half the messages would go to B1 and half to the AB1/AB2 systems each time the message is moved. If AB1 or AB2 is down there is no choice left and the messages go to the B1 system.

The solution is to use a different name for the qmgr alias in AB1, AB2

DEF QREMOTE(B1B1) RQMNAME(B1) RNAME(' ') CLUSTER(B)
Back to top
View user's profile Send private message
vennela
PostPosted: Mon Sep 16, 2002 7:08 am    Post subject: Reply with quote

Jedi Knight

Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India

This is what is happening exactly.

Quote:
a message arriving in say AB1 would have a choice of the real B1 or its alias in AB2 as its next destination. On average half the messages would go to B1 and half to the AB1/AB2 systems each time the message is moved


I didn't implement the setup. I was called in to look at why things were weird. I will check all the definitions and see what is happening.

---
Venny
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » Clustering » Clustering slows down the process drastically
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.