| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Group Id...Revisited... |
« View previous topic :: View next topic » |
| Author |
Message
|
| mqonnet |
 Posted: Thu Feb 21, 2002 9:53 am Post subject: |
 |
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
Hi Mqer's,
I have a very basic but a bit confusing question regarding Group Id's.
Group id's are Unique and are generated by the Queue manager. Consider the
following scenario.
I have a putting app which puts 7 messages in 2 groups of 4 and 3
messages.
4 Messages in Group 1.
3 Messages in Group 2.
As per the documentation it is says "Message groups and segments can be
processed correctly only if the group identifier is unique". Which means
that messages could be processed correctly if the Groupid is Unique. But
the statement does not tell you that in the event that there are two groups
with the same groupid, the Queue manager WILL NOT process them correctly.
It just says that the probability of error is there. Thus my question is.
If we consider the above scenario and see that we have 2 groups with the
SAME GROUPID,
1) how would the messages be processed.
2) At the first place, would the getting app or the Queue manager get
confused about this.
3) Has anyone faced this situation earlier. And is it possible.
4) If this happens on a stand alone system, guess that would be fine. But
what if we consider that these messages in groups need to be sent accross
channels to some other Box. Would these messages get mixed up when they
reach the other end. Because Order of delivery is never guarenteed.
I had a theory for this and wanted to share with all of you and wanted to
get your opinions on this.
I think that even though the documentation says that group id if unique,
things would go ok, it does not say that it would not behave otherwise if we
dont have a unique groupid. And thus, i guess it might or rather work fine
in the case of a stand alone server case. When the putting app puts 4
messages, all of them get say "group1" as the unique group id. Now when the
second grouped messages are put they also say get the same group "group1" as
the groupid assigned by the QM. Now the getting app just gets the message
by LOGICAL_ORDER. And so what it does is, assigns the First group as the
local group and gets all the messages(4), and why only 4, because the 4th
message is LAST_MSG_IN_GROUP. Now, the next group becomes the local group
and thus this is again processed smoothly. Logically speaking this theory
seems to be convincing. Any comments on this would be great.
Also include the point of view that the user SETS this value for both groups
to be the same.
Cheers.
Kumar
_________________
IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator |
|
| Back to top |
|
 |
| bduncan |
| Posted: Thu Feb 21, 2002 3:09 pm Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Kumar,
You are basically right with your theory, but you are only addressing a small subset of the possible ways you can end up with multiple groups with the same group ids. In some other scenarios, bad things can happen.
Let's consider the following situation. As you mentioned, you have 4 messages in group 1 and 3 messages in group 2. Let's pretend the message ids for group 1 are a,b,c, and d, and the message ids for group 2 are x,y, and z. Both d and z are LAST_MSG_IN_GROUP.
Now, in your scenario, you had an application put a,b,c,d followed by x,y,z. And as you guessed, the receiving end will handle this fine even though the group ids are the same. But now consider the following scenario. Instead of the same application putting both groups, let's say 2 different applications are putting them. Again, both groups will have the same group ids. Now, both groups of messages are being put to the same queue. Let's say the messages end up on the queue in the following order: a,x,y,b,z,c,d.
Now when the getting application tries to get these messages (in FIFO order) it will specify LOGICAL_ORDER, which means it is going to get the first message in a group (signified by a sequence number of 1) and continue getting messages in the group in order (by looking for sequence number 2, 3, etc...) until it gets a message with LAST_MSG_IN_GROUP specified.
Now, we are going to get message 'a' first. It has a sequence number of 1. Now we are going to look for a message on the queue with sequence number of 2, *with the same groupid* as message 'a'. Well, message 'x' is next on the queue, but it has a sequence number of 1, so it is ignored (the queue manager doesn't even bother to notice the groupid of 'x' is the same as 'a'). The next message is 'y', and it fits the criteria. It has a sequence number of 2, and upon further inspection, the same groupid as message 'a'.
Now, you see how we get into trouble here. In a nutshell, we will process: a, y, z (we stop at 'z' because it has LAST_MSG_IN_GROUP specified) as one group, and x, b, c, d as another group. Which could potentially spell big trouble...
To answer another of your questions, I have never run into this problem before, except for when I created the problem on purpose, to answer the very same questions you asked. If you depend on the queue manager to supply you with a group id (rather than specifying it yourself), you shouldn't ever run into duplicates...
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator
[ This Message was edited by: bduncan on 2002-02-21 15:10 ] |
|
| Back to top |
|
|
| mqonnet |
| Posted: Fri Feb 22, 2002 6:31 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
Hi Duncon,
This is precisely what i was concerned about. If we have two apps or two instances of the same app putting messages with same group id. Things get dicy. This situation has not been handled anywhere. Not sure if it needs to be. I might be wrong on this one, but when i was running the same app with two instances, i saw ONLY ONCE that NT 5.2 generated the same groupid for both the apps. I could never reproduce this problem again. And dont know if it was the QM or me who was at fault. But since i have tried in vain reproducing the same problem under the same circumstances and scenario with the same applicaiton, i thought it might just be a figment of my imagination that i saw there. But it thus triggered off the theory i put up in my discussion earlier.
I know this is a very vague scenario, but do you think this needs to be addressed or...
Cheers
Kumar
_________________
IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator |
|
| Back to top |
|
|
| bduncan |
| Posted: Fri Feb 22, 2002 1:02 pm Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Kumar,
I would be suprised if the situation you described actually happened, because as far as I'm aware, when the queue manager creates a group id, it does it in much the same way it creates a message id. That is, the group id is a combination of a timestamp and queue manager identifier concatenated together. So presumeably you won't run into duplicates. I remember that someone (can't remember who) corrected me a while back when I said that message ids created by the queue manager were GUARANTEED to be unique. He pointed out that they "usually" (as in basically always) are unique, but there was no gaurantee of it. I think the same applies to group ids. You should never ever in your lifetime see a duplicate group id, but there is no check or rule in the queue manager that prevents this situation from arising.
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
