| Author |
Message
|
| mpsmith19 |
 Posted: Wed Jun 01, 2005 7:10 am Post subject: Contents of a generated MsgId |
 |
|
Novice
Joined: 02 May 2005
Posts: 20
|
Using MQ 5.3, C API, working with several "inheritted" legacy applications.
My users are reporting that 1 out of the 15 applications never retrieves the proper message when 2 messages are generated at the same time (relatively). They report that if 2 people generate a message, the 2nd person to generate a message gets the first response instead of the 2nd response. The messages are being generated in about the same second.
I took a look at the MQMD.MsgId field and found something interesting. The 17th character is always a binary 0. I checked the other 14 applications and none of them ever have a binary 0 in position 17.
Perhaps I missed it, but I can't find anything about specifying a certain version or setting a flag to generate a unique MsgId.
Any help is appreciated.
Michael P. Smith |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Wed Jun 01, 2005 7:14 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
So, here's the deal.
Your code, somewhere, is trying to treat the Message ID field as a character string - which is terminated by a binary 0 (as all good programmers know).
The method to instruct MQ to generate a new unique message ID is a set of options on the PUT call, including setting the message ID to an empty string first.
The Message Id and Correlation Id fields are now and have always been defined as byte arrays, not character arrays or string arrays. You can not instruct WebSphere MQ to create a new, unique msgId that does not have binary 0's in it - it will do it or it won't.
The method of generating unique id's that MQ uses changed with version 5.3 (I think? was it at CSD5?).
You'll have to adjust your code to take into account that the fields are byte arrays and not character arrys - or generate your own MsgIds (which is not recommended).
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| mpsmith19 |
| Posted: Wed Jun 01, 2005 7:38 am Post subject: |
|
|
Novice
Joined: 02 May 2005
Posts: 20
|
That's what I thought at first. Aside from my Trace function and HexDump function (neither of which modify the MsgId), the ONLY place the MsgId is referenced is when it is initially set (per the manual):
| Code: |
memcpy(mqmdDesc.MsgId, MQMI_NONE, sizeof(mqmdDesc.MsgId));
|
Here's the output from a Trace call which in turn calls the HexDump call:
| Code: |
10:26:12.910 MsgId for message: <AMQ SLTMQHTPHT > <hex 41-4d-51-20-53-4c-54-4d-51-48-54-50-48-54-20-20-00-ab-67-42-20-04-21-01->
|
Oh, and here are the MQPMO.Options
| Code: |
mqpmoOptions.Options = MQPMO_NEW_MSG_ID + MQPMO_SET_IDENTITY_CONTEXT;
|
Any other thoughts?
Michael P. Smith
The Inept MQ Programmer  |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Jun 01, 2005 7:51 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You're looking at the wrong code.
What mechanism is used to match the request with the response?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| mpsmith19 |
| Posted: Wed Jun 01, 2005 1:15 pm Post subject: |
|
|
Novice
Joined: 02 May 2005
Posts: 20
|
| jefflowrey wrote: |
You're looking at the wrong code.
What mechanism is used to match the request with the response? |
Are you referring to the code running on the MQ Server itself? If so, I don't have access to that code and it appears to be working for the other 14 applications just fine.
Or are you perhaps referring to my MQGET function as opposed to my MQPUT function? I'm relying on MQ to generate the unique MsgId, and I get that from the MQPUT and pass it to the MQGET. I do this by passing basically the same MQMD variable to both MQPUT and MQGET.
Please forgive me if I misunderstood your response. This is someone elses legacy code I'm working with, and I'm not very familiar with MQ (learning as I go).
Michael P. Smith |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Jun 01, 2005 1:18 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Yes Michael we would like to have a look at the code that matches the correlationID to the MessageID in your application.
Like Jeff said we suspect it may be due to some handling of a byte array as a different animal...
 |
|
| Back to top |
|
|
| mpsmith19 |
| Posted: Wed Jun 01, 2005 3:36 pm Post subject: |
|
|
Novice
Joined: 02 May 2005
Posts: 20
|
| fjb_saper wrote: |
Yes Michael we would like to have a look at the code that matches the correlationID to the MessageID in your application.
Like Jeff said we suspect it may be due to some handling of a byte array as a different animal...
|
The problem has been solved. Was finally able to get the user to describe the conditions that caused the problem well enough to duplicate it on my test system. Within a few minutes it became apparent that a static variable that was keeping track of the connection was being shared among multiple IE sessions. Got to thank Microsoft IIS Pooling and ISAPI callbacks for allowing two sessions to run under a single process (DLLHOST) and step on each others static variables.
Also, the binary 0 in position 17 of the MsgId turned out to be perfectly valid. Examination of the 24byte MsgId revealed that the last 8 bytes of the MsgId were indeed changing enough to be unqiue and that the binary 0 was just part of that uniqueness. Unfortunately, seeing the binary 0 at the end of a normal string of characters got me to think that the program was manipulating the data incorrectly, or that MQ was not returning a unique MsgId. Both thoughts were incorrect.
Michael P. Smith |
|
| Back to top |
|
|
|
|
