| Author |
Message
|
| kigoe |
 Posted: Mon Jun 28, 2010 1:57 am Post subject: Correlation ID issue |
 |
|
Newbie
Joined: 28 Jun 2010
Posts: 8
|
Hi all, I'm having a problem setting a correlation ID on an MQMD header using a java class. I'm also writing the Appld, replyToQ & replyToQMgr. These attribute are getting set fine.
When writing to a local queue, the correlation ID seems to stay in place, but when I write to a remote queue, the ID seems to get over-written with an ID that looks very similar to the message id.
I've tried a few different methods, none of which work. Here are some code examples (setting other attributes apart from correlation id work fine):
| Code: |
...
...
TextMessage outMsg = session.createTextMessage();
outMsg.setText(msg);
outMsg.setObjectProperty(WMQConstants.JMS_IBM_MQMD_APPLIDENTITYDATA, applId);
outMsg.setObjectProperty(WMQConstants.JMS_IBM_MQMD_REPLYTOQ, replyToQ);
outMsg.setObjectProperty(WMQConstants.JMS_IBM_MQMD_REPLYTOQMGR, replyToQMgr);
byte[] correlId = generateCorrelationId(threadId);
if(correlId != null){
outMsg.setObjectProperty(WMQConstants.JMS_IBM_MQMD_CORRELID, correlId);
}
|
I have also tried this:
| Code: |
// Set as a string, does not work
outMsg.setJMSCorrelationID(threadId);
|
And also tired this: but get the following exception
Caught Exception: JMSCC0050: The property name 'JMSCorrelationID' is reserved and cannot be set.
| Code: |
outMsg.setObjectProperty(WMQConstants.JMS_CORRELATIONID, correlId);
|
Any suggestions on this would be greatly appreciated as I have tried everything I can think of and also worked very closely with some very experienced MQ folks but can't get tot the bottom of it. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Mon Jun 28, 2010 8:04 am Post subject: Re: Correlation ID issue |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| kigoe wrote: |
| also worked very closely with some very experienced MQ folks but can't get tot the bottom of it. |
Well I'm that but my Java is highly suspect. However, it's my (possibly flawed) understanding that the JMS standard reserves correl id for system use and it's read only. This would seem to be borne out by the error message you're getting.
One thing I do know is that setting correl id to anything that isn't a message id is a highly suspect design, in Java or any other language. I cetainly don't understand why (if I'm reading your code correctly) you're trying to use a thread id to identify a message... 
Many, many discussions on this subject in here you might find useful.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| kigoe |
| Posted: Mon Jun 28, 2010 8:21 am Post subject: |
|
|
Newbie
Joined: 28 Jun 2010
Posts: 8
|
Thanks Vitor, the reason I'm setting a correlation id is that I have a unique process thread id (note, this is not a java thread id) that I generate for every message (separate to the correlation id or message id)
This process id is used during one execution of a message through the system. It sends a message out to an external third party at the end of the process and the third party sends an ACK in response to this message. I need to link the ACK with the message that was send out from my application. If I let the system pick it's own correlation id, i have no way of knowing what it is before the message is sent.
I have read a few posts here and some people are doing what I'm trying to do with no issue. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jun 28, 2010 8:24 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| kigoe wrote: |
| I need to link the ACK with the message that was send out from my application. If I let the system pick it's own correlation id, i have no way of knowing what it is before the message is sent. |
Yes you do - it's the message id of your original message. That's the conventional pattern in request reply; to use the original message id to correlate the reply (hence the name).
| kigoe wrote: |
| I have read a few posts here and some people are doing what I'm trying to do with no issue. |
Then clearly I'm wrong. I did warn you Java isn't my thing.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Jun 28, 2010 10:14 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Vitor wrote: |
| kigoe wrote: |
| I need to link the ACK with the message that was send out from my application. If I let the system pick it's own correlation id, i have no way of knowing what it is before the message is sent. |
Yes you do - it's the message id of your original message. That's the conventional pattern in request reply; to use the original message id to correlate the reply (hence the name). |
No, you don't know what the message ID is going to be before you send the message, unless you create the message ID yourself. But you explicitly can't do that with JMS.
You do know what the message ID is immediately *after* you send the message, it's updated in the MQMD that is passed to the MQPUT, and I believe JMS updates the message object after the send as well.
From what I recall of JMS, and it's been too long since I've done it in practice, using the setCorrelationID should be fine, but you might have to use a hex value to avoid manglement. It might also be that the ID is being properly set, but kigoe is misunderstanding that the output value is likely turned into hex. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Jun 28, 2010 7:07 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
If you really need a correlation Id generator use a message with very little TTL (Time to live) and get its messageId . You can then use it as correlation id on the next message you send... prospective cost of the put about 4 ms + network....
You can also alternatively try to set the message options with the appropriate value for MQ to generate the correlation Id and retrieve it from the message immediately after send. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| kigoe |
| Posted: Tue Jun 29, 2010 12:54 am Post subject: |
|
|
Newbie
Joined: 28 Jun 2010
Posts: 8
|
Hi All, thanks so much for your replies. I am setting the id as a Hex value and, as I said, if I write to a local queue I can see the message with the correct correlation id. (I'm using IR360 application to view this)
The problem is when I write to a transmission (remote) queue. (I can see the message on the queue before it is transmitted as the transmission channel is switched off temporarily)
When the message is sitting on the queue, its correlation id is completely different to the one I just set, although it is very similar to the message id. I'm thinking that somewhere in the configuration of the queue, there is some parameter that uses the message id to over-write my correlation id. I just don't know where that could be.
In relation to mqjeff's suggestion that I'm misunderstanding the value after it's turned into HEX, at first I thought that might have been the case but then I realized how it works and I can say I'm 100% sure that this is not the case. A colleague had an old IBM "yellow card" lying around which turned out to be very useful in figuring this out.[/quote] |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jun 29, 2010 2:28 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
The message on the transmission queue has a transmission header on it. The transmission header has a different MQMD...
Try putting the message to a local queue instead of a remote queue. |
|
| Back to top |
|
|
| kigoe |
| Posted: Tue Jun 29, 2010 2:45 am Post subject: |
|
|
Newbie
Joined: 28 Jun 2010
Posts: 8
|
| Thanks mqjeff. That's interesting. The message gets sent to an external company so I presume that is why it needs to go to a remote queue. I'm not that up to date on the whole mechanics of mq transmission so if I can send a message to an external company using a local queue then that sounds like the solution. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jun 29, 2010 2:53 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
No, no.
Send the message to a local queue for *testing*. Just to confirm that it looks the way it should.
You'll need to send it to the qremote to get it to go anywhere. |
|
| Back to top |
|
|
| kigoe |
| Posted: Tue Jun 29, 2010 3:25 am Post subject: |
|
|
Newbie
Joined: 28 Jun 2010
Posts: 8
|
| Thanks mqjeff. Therein lies the problem. It works for local queues but not for remote queues. You say the tranmission header has a different mqmd. Is there a way to set the transmission queue to have a correlation id equal to the correlation id that I set on the message? Would this be something in the configuration of the queues? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jun 29, 2010 3:29 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Ignore the transmission header.
If it works for local queues, it *works*.
The transmission header is removed on delivery- it is only used by the channel agent.
You could verify this yourself by setting up another queue manager and sending a message to it via a qremote. |
|
| Back to top |
|
|
| kigoe |
| Posted: Tue Jun 29, 2010 3:42 am Post subject: |
|
|
Newbie
Joined: 28 Jun 2010
Posts: 8
|
I have tested sending to the external company and it is coming back with the correlation id that I see on the remote queue before it sends, which is not the one I set.
I could do some testing as you suggest below. Thanks for all your input, it helps to understand how it all hangs together |
|
| Back to top |
|
|
| shrey_2109 |
| Posted: Fri Mar 11, 2011 5:28 am Post subject: |
|
|
Newbie
Joined: 11 Mar 2011
Posts: 2
|
I am facing similar issue , can some one please tell what is the solution to the problem , is there any property whcch should be set on reply message to indicate MQ Queue manager to not override correlation ID .
Cheers,
Shrey |
|
| Back to top |
|
|
| kigoe |
| Posted: Sat Mar 12, 2011 8:27 am Post subject: |
|
|
Newbie
Joined: 28 Jun 2010
Posts: 8
|
Hi Shray,
The solution I implemented was to read and store the correlation id of the message after it was put on the transmission queue, you still have access to the message after it's been send, I then read the correlation id of the reply message and matched it up to an id that I had stored for my processing. It's working perfectly in a live environment now. |
|
| Back to top |
|
|
|
|
