(FYI: the reason I am trying to do this, is that I am using the correlation
id to group messages together using a GUID)
Thanks in advance, Leslie Keane
Saranac Consulting, Inc.
A correlation id is 20 octets. A GUID is 16 octets. I'm not surprised
that you get an error.
> (FYI: the reason I am trying to do this, is that I am using the correlation
> id to group messages together using a GUID)
Why not send the first message with an app-specific property to set to
x-1 where x is the number of messages in the group - you might even
assign "Part 1" as a label if you'd like. Then as a new message
in the group is sent, assign the the msgid of the first message, and
decrement the app-specific property by 1 until all are sent.
Incidentally, if you send the messages in a single transaction, they
are guaranteed to arrive in order (though not necessarily in consecutive
order).
--
Alan Dickman, Architect, al...@pswtech.com, http://www.pswtech.com/~alan
== Providing distributed object, transaction processing, deployment, ==
== and operational preparedness consulting to customers world=wide. ==
=======================================================================
== PSW Technologies, http://www.pswtech.com, +1 800 933 2876 x3113 ==
== Home Office: 1537 Coyote Court, Golden, CO 80403, +1 303 273 5688 ==
If you look at the appropriate status word for the property you are
probably getting 0xC00E003B which is MQ_ERROR_ILLEGAL_PROPERTY_SIZE.
Although the SDK says that Correlation ID is user defined with a maximum
length of 20 bytes, it appears that it is really user defined with a fixed
length of 20 bytes. Calling MQSendMessage or MQReceiveMessage with
caub.cElems set to anything other than 20 produces this error.
You can set the correlation id to any value you like so long as you *say*
it is 20 bytes long. For example the following works...
UCHAR CorrId[MAX_BUFFER]; // Waste of space, we only need 20
bytes.
// Set the Correlation ID of the message
strcpy (CorrId, "Correlation Id 1");
amPropId[cProps] = PROPID_M_CORRELATIONID;
aPropVar[cProps].vt = VT_UI1 | VT_VECTOR;
aPropVar[cProps].caub.cElems = 20;
aPropVar[cProps].caub.pElems = CorrId;
cProps++;
Even though the string is only 16 bytes long (actually 17 with the null),
and the buffer itself is way longer than 20 bytes, I lied and set
caub.cElems to 20. Of course if the string had been longer than 20 bytes,
I'd only have got the first 20 bytes as my correlation ID.
This looks to be a bug, perhaps in the implementation or perhaps in the
documentation, but a bug nonetheless.
Does this have something to do with the app specific property that holds the
message number within the transaction?
Thanks!
John
>
When you send messages a, b, c, and d within a transaction, MSMQ
guarantees
that the message a arrives in the target queue before b, b before c, and
c
before d. However, other applications may be sending messages z, y, and
x.
It doesn't guarantee messages are ordered consecutively: a, b, c, d, z,
y, x.
Among the possible orderings is: a, z, b, y, c, x, d.
> Does this have something to do with the app specific property that holds the
> message number within the transaction?
No. However, you could use the app-specific counter to indicate the
number of
messages in the "set". In addition, you could use the msg id from a as
the
correlation id for b, c, and d. The use of the msg id enables the
receiver
to correlate b, c, and d to a (thus forming a complete set).
--
Alan Dickman, Architect, al...@pswtech.com, http://www.pswtech.com/~alan
+- PSW Technologies, http://www.pswtech.com, +1 800 933 2876, x3113 -+
+- Home Office: 1537 Coyote Court, Golden, CO 80403, +1 303 273 5688 -+
+---------------------------------------------------------------------+
+- Providing distributed object, transaction processing, deployment, -+
+- and operational preparedness consulting to customers world-wide. -+
+- Developing Applications Using MSMQ :: From Addison Wesley in 2Q98 -+