| Author |
Message
|
| starki78 |
 Posted: Mon Jan 02, 2012 5:23 am Post subject: In which cases Correlation-ID needs to be in binary format? |
 |
|
Acolyte
Joined: 24 Sep 2007
Posts: 53
|
Hello,
from time to time we step about the usecase
that a Correlation-ID scenarios works only when the
Correlation-ID is in binary.
In this scenarios the message gets sent to MQ-request queue
and then put to MQ-response queue.
Is there any setting or environment (Mainframe?) which is requiring the Correlation-ID being binary?
Thanks and Regards
Starki |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Mon Jan 02, 2012 5:35 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
It's not a requirement that the correlation ID is a binary string.
It's a fact. The fundamental definition of the Correlation ID field is a string of 24 bytes.
Regardless of platform, the contents of this field are always treated as bytes by the MQ product code.
Your application is free to reinterpret these bytes as whatever you want, but you must write your application being mindful of the facts. |
|
| Back to top |
|
|
| starki78 |
| Posted: Mon Jan 02, 2012 5:56 am Post subject: |
|
|
Acolyte
Joined: 24 Sep 2007
Posts: 53
|
thanks for your reply.
In my situation we send the Correlation ID
as a HEX-String.
But it is not interpreted correctly on MQ-Side.
Hence is the correct solution of this is that we must
generate the byte value of the HEX-String
and send it?
I cannot reproduce locally on Windows or Linux but
if I understand you correctly this is just be coincidence
Thanks
Starki |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Jan 02, 2012 6:24 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
| starki78 wrote: |
thanks for your reply.
In my situation we send the Correlation ID
as a HEX-String.
But it is not interpreted correctly on MQ-Side.
Hence is the correct solution of this is that we must
generate the byte value of the HEX-String
and send it?
I cannot reproduce locally on Windows or Linux but
if I understand you correctly this is just be coincidence
Thanks
Starki |
What evidence do you see that makes you believe this is the case?
What are you using the CorrelId field for?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| starki78 |
| Posted: Mon Jan 02, 2012 6:33 am Post subject: |
|
|
Acolyte
Joined: 24 Sep 2007
Posts: 53
|
it's a classical request response scenario.
byte byteArray[] = xmlString.getBytes();
outMessage.correlationId = byteArray;
outMessage.replyToQueueName = sResponseQueueName;
outMessage.writeString(xmlString);
now if I would set
outMessage.correlationId
as String it is not working.
I need to understand that this is Works As Designed
and why I cannot reproduce it in my testenvironment where it works
just to set a String
Thanks
Starki |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Jan 02, 2012 7:12 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
| starki78 wrote: |
it's a classical request response scenario.
...now if I would set
outMessage.correlationId
as String it is not working.
|
"it is not working" is not a technical explanation of a symptom.
Again, exactly what evidence to you see that leads you to believe that it is not working?
The usual request-reply model presumes that requesting app will seed the MsgId field with a unique MsgId; and that the replying app will copy the inbound MsgId into the CorrelId field of the reply message.
So, are you saying that the requesting app does not successfully mqget a reply (or report) message from the reply-to-queue?
Is the program code you posted from the requesting app? Or the replying app?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| starki78 |
| Posted: Mon Jan 02, 2012 7:20 am Post subject: |
|
|
Acolyte
Joined: 24 Sep 2007
Posts: 53
|
the code is from the sender application.
I've no control on the MQ-Series side.
Not working means that the Response-Message cannot be correlated to the Request Message if I don't set the Correlation-ID as binary
This is a dummy implementation of the response side may look like:
outMessage.setJMSCorrelationID(msg.getJMSCorrelationID());
or I assume something like:
outMessage.setJMSCorrelationID(byteArrayToHexString(msg.getJMSCorrelationIDAsBytes()));
I need to understand why binary is required
and if there are any usecases where this is a must |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Jan 02, 2012 7:29 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| mqjeff wrote: |
| The fundamental definition of the Correlation ID field is a string of 24 bytes. |
Sorry Jeff but your language is somewhat confusing here.
If you meant that to be a JMS specification quote, please say so.
In all of WMQ the Correlation ID is treated as a BYTE ARRAY and not a string.
You may have a string representation in hex of the byte array (48 chars).
This has particular meaning in C when you consider a byte array vs a string and take into consideration the string termination byte values...
Also remember that in any language a byte can have illegal values if cast to a char.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Jan 02, 2012 7:34 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
This is from the WMQ APR manual:
| Quote: |
MQBYTE - byte
The MQBYTE data type represents a single byte of data. No particular
interpretation is placed on the byte; it is treated as a string of bits, and not as a binary number or character. No special alignment is required.
When MQBYTE data is sent between queue managers that use different character sets or encodings, the MQBYTE data is not converted in any way. The MsgId and CorrelId fields in the MQMD structure are like this. |
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Jan 02, 2012 7:41 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| starki78 wrote: |
| Not working means that the Response-Message cannot be correlated to the Request Message if I don't set the Correlation-ID as binary |
Sounds about right
| starki78 wrote: |
This is a dummy implementation of the response side may look like:
outMessage.setJMSCorrelationID(msg.getJMSCorrelationID());
|
This should be enough. However consider the case where you need to populate with getJMSMessageID(), because the correlation id is a byte array filled with '00'. (MQCI_NONE)
| starki78 wrote: |
or I assume something like:
outMessage.setJMSCorrelationID(byteArrayToHexString(msg.getJMSCorrelationIDAsBytes()));
I need to understand why binary is required
and if there are any usecases where this is a must |
This part would be wrong. Note that the "Provider" version of the correlationId looks like "ID:"+hex_values_of_bytearray.
It would have been better here to use setJMSCorrelationIDAsBytes()...
You may want to  the relevant sections of the using Java manual again.
Have fun
_________________
MQ & Broker admin
Last edited by fjb_saper on Mon Jan 02, 2012 8:35 am; edited 1 time in total |
|
| Back to top |
|
|
| starki78 |
| Posted: Mon Jan 02, 2012 8:18 am Post subject: |
|
|
Acolyte
Joined: 24 Sep 2007
Posts: 53
|
thanks for your feedback.
I do not understand this:
This should be enough. However consider the case where you need to populate with getJMSMessageID(), because the correlation id is a byte array filled with '00'.
We use the Correlation-ID pattern and the correcltation id is never 0.
My problem is that I've no insight how in the real world the Correlation-ID is retrieved and set.
I just know that setting it to string is not working
and wanted to find out from where this limitation is coming from
Thank you |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Jan 02, 2012 8:25 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
| starki78 wrote: |
...
My problem is that I've no insight how in the real world the Correlation-ID is retrieved and set.
I just know that setting it to string is not working
and wanted to find out from where this limitation is coming from |
The request-reply model is well documented in both the WMQ Application Programming Reference, and WMQ Application Programming Guide (and InfoCenter equivalents). The official documentation offers coding examples.
WMQ implements a small number of data-types. A BYTE field is not the same as a CHAR field.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| starki78 |
| Posted: Wed Jan 04, 2012 7:59 am Post subject: |
|
|
Acolyte
Joined: 24 Sep 2007
Posts: 53
|
I finally got the Stacktrace from MQ-Side:
Does anybody have a MQ-sample which could reproduce this error below?
SystemErr R java.lang.NumberFormatException: For input string: "2asasas89"
at java.lang.NumberFormatException.forInputString(NumberFormatException.java(Compiled Code))
at java.lang.Integer.parseInt(Integer.java(Compiled Code))
at java.lang.Integer.parseInt(Integer.java(Compiled Code))
at com.iflex.fcat.exchange.RequestResponseProcessor.processRequest(RequestResponseProcessor.java:345)
at com.iflex.fcat.exchange.RequestResponseProcessorMDB.processRequest(RequestResponseProcessorMDB.java:154)
at com.iflex.fcat.xjava.mdb.MessageQueueMDB.onMessage(MessageQueueMDB.java:248)
at com.ibm.ejs.jms.listener.MDBWrapper$PriviledgedOnMessage.run(MDBWrapper.java:319)
at com.ibm.ws.security.util.AccessController.doPrivileged(AccessController.java(Compiled Code))
at com.ibm.ejs.jms.listener.MDBWrapper.callOnMessage(MDBWrapper.java:288)
at com.ibm.ejs.jms.listener.MDBWrapper.onMessage(MDBWrapper.java:266)
at .run(MQSession.java:1768)
at com.ibm.ejs.jms.JMSSessionHandle.run(JMSSessionHandle.java:972)
at com.ibm.ejs.jms.listener.ServerSession.connectionConsumerOnMessage(ServerSession.java:862)
at com.ibm.ejs.jms.listener.ServerSession.onMessage(ServerSession.java:627)
at com.ibm.ejs.jms.listener.ServerSession.dispatch(ServerSession.java:594)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:5
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java(Compiled Code))
at java.lang.reflect.Method.invoke(Method.java(Compiled Code))
at com.ibm.ejs.jms.listener.ServerSessionDispatcher.dispatch(ServerSessionDispatcher.java:37)
at com.ibm.ejs.container.MDBWrapper.onMessage(MDBWrapper.java:91)
at com.ibm.ejs.container.MDBWrapper.onMessage(MDBWrapper.java:127)
at com.ibm.ejs.jms.listener.ServerSession.run(ServerSession.java:479)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1475)
Thanks Starki |
|
| Back to top |
|
|
|
|
