| Author |
Message
|
| knappes |
 Posted: Mon Oct 23, 2006 1:43 am Post subject: Communication JMS - MQPlain |
 |
|
Newbie
Joined: 23 Oct 2006
Posts: 6
|
Hi
in one of our applications we have to exchange messages with a remote queue. We are using the standard JMS Api to send and retrieve messages.
While this is working quite fine we encountered one problem. We are not able to dequeue response messages via jms-messageselectors (JMSCorrelationID = 'ID:xxxxx...'). Our communication partner uses plain mqseries (even non java based) and it seems, that the correlationID they set do not match our original message ids (CID seems to be shorter).
So, here my questions:
What could be the reason for this strange beaviour ?
Is it generally possible to get messages via jms-selectors if the "other side" only sets native (bytes) correlation ids ? |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Mon Oct 23, 2006 1:49 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You can't issue an MQGet against a QREMOTE. You can only issue MQGets against QLocals on the queue you are connected to.
This means you can send to a "remote queue", but you can't "retrieve" from one.
Make sure you are not trying to GET from a queue that is not local to the queue manager you are connected to.
And then double-check, using something like amqsbcg or amqsbcgc, that the correlation IDs on the messages you are trying to get are right or wrong. Until you actually look at the message id's and correlation ids, you'll only be guessing.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| knappes |
| Posted: Mon Oct 23, 2006 2:07 am Post subject: |
|
|
Newbie
Joined: 23 Oct 2006
Posts: 6
|
In fact we try to dequeue the messages from a local queue.
We do retrieve the original message id from the request-message. It is a 48bit-String perfixed with ID. Then we try to receive the response with a selector that includes the original message id |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Oct 23, 2006 2:14 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| knappes wrote: |
In fact we try to dequeue the messages from a local queue.
We do retrieve the original message id from the request-message. It is a 48bit-String perfixed with ID. Then we try to receive the response with a selector that includes the original message id |
Okay, standard disclaimer about my lack of Java.... 
I wouldn't know a jms selector if it fell on my foot (unless it had a label with "JMS Selector" on it) but both MSgId & CorrelId are not strings but byte arrays, not commonly prefixed with "ID" in my experence.
Treating them as strings in non-Java languages ends badly. As does trying to create them within an app & not letting MQ do it.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| knappes |
| Posted: Mon Oct 23, 2006 2:23 am Post subject: |
|
|
Newbie
Joined: 23 Oct 2006
Posts: 6
|
Hi Vitor,
the message ids are set by mqseries. As far as I JMS translates the native byte array to a hex representation. You can use it to retrieve messages via selectors. Internally the mqmessage should still hold the native message id which is processed on the server side and attached as correlation id. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Oct 23, 2006 2:26 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| knappes wrote: |
Hi Vitor,
the message ids are set by mqseries. As far as I JMS translates the native byte array to a hex representation. You can use it to retrieve messages via selectors. Internally the mqmessage should still hold the native message id which is processed on the server side and attached as correlation id. |
My Java knowledge grows, and I thank you. 
Have you done as suggested by jefflowrey and checked the correlation id actually contains the values you believe it does?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Oct 23, 2006 2:39 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Please do not set the correlationId. JMS will allow you to set a correlation Id that is more than 24 Bytes. MQ base will truncate it at 24 bytes...
However you are dealing at the other end with a non JMS application. Don't set the correlationId on the request message. Get the messageId and use it for selector against the correlationId field. If the server application is well behaved it will return the request messageId in the correlationId field when the correlationId on the request message is empty (MQMI_NONE). [edit]If the correlationId is set it is a passthrough from request to reply message.[/edit]
And you will have implemented an anonymous message identifier pattern...
Enjoy
_________________
MQ & Broker admin
Last edited by fjb_saper on Mon Oct 23, 2006 3:02 am; edited 1 time in total |
|
| Back to top |
|
|
| knappes |
| Posted: Mon Oct 23, 2006 2:46 am Post subject: |
|
|
Newbie
Joined: 23 Oct 2006
Posts: 6
|
| Well, we (the client side) do not set the correlationId - it is in fact null when sending a request. We found out that all correlationIds in the response messages contain the same (?!?!?) correlationId. Seems strange to me... |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Oct 23, 2006 2:49 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| knappes wrote: |
| We found out that all correlationIds in the response messages contain the same (?!?!?) correlationId. Seems strange to me... |
Then the next move is to politely ask your communication partners what they believe they're setting the correl ids to. If it's well behaved (as per fjb_saper above) it's the original msg id. If it's not, or is well behaved with just the smallest bug you might get this effect.... 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Oct 23, 2006 3:19 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| knappes wrote: |
| Well, we (the client side) do not set the correlationId - it is in fact null when sending a request. We found out that all correlationIds in the response messages contain the same (?!?!?) correlationId. Seems strange to me... |
This also explains why your get isn't working. Your selector does not match what is actually in the message - so there's nothing to select and you get back no messages.
But like I said, until you look at the message and correlation id's yourself, you'd never know that for sure.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| knappes |
| Posted: Mon Oct 23, 2006 3:30 am Post subject: |
|
|
Newbie
Joined: 23 Oct 2006
Posts: 6
|
| Anouther encounter: It seems that the correlation ids contain only 14 valid bytes, padded with 10 "0-Bytes". Could this be an encoding problem ? |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Oct 23, 2006 3:33 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| knappes wrote: |
| Anouther encounter: It seems that the correlation ids contain only 14 valid bytes, padded with 10 "0-Bytes". Could this be an encoding problem ? |
It's certainly a problem with someone's coding... 
If by encoding you mean CCSID / code page / etc, the id fields are byte fields and therefore the same on all platforms. This is why they're byte arrays and not strings.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| knappes |
| Posted: Mon Oct 23, 2006 4:53 am Post subject: |
|
|
Newbie
Joined: 23 Oct 2006
Posts: 6
|
| Ok, the customer was wrong, Problem solved..... |
|
| Back to top |
|
|
|
|
