Author |
Message
|
rebornspirit |
Posted: Tue Jun 21, 2005 5:12 am Post subject: Every 16th message retrieval fails with a 2033 error code??? |
|
|
Newbie
Joined: 21 Jun 2005 Posts: 8
|
I'm having a strange problem...
I have a java function (see below) that submits a message to a queue and waits until a response message is received (based upon correlation id). Everything seems to work fine, but ... every 16th message retrieval fails upon a 2033 error code. The messages following upon the 16th will work until it tries to retrieve the next 16th message and so on and so on ...
Code: |
byte[] messageOutId = null;
MQQueueManager queueManager = null;
try {
// Sent
queueManager = connect(host, channel, port, queueManagerName);
MQQueue queue = openQueue(queueManager, syncQueueOut, MQC.MQOO_OUTPUT);
try {
MQMessage messageOut = new MQMessage();
messageOut.writeUTF(messageOutContents);
messageOut.messageType = MQC.MQMT_REQUEST;
messageOut.format = MQC.MQFMT_STRING;
messageOut.expiry = syncExpiry;
messageOut.replyToQueueManagerName = queueManagerName;
messageOut.replyToQueueName = syncQueueIn;
MQPutMessageOptions pmo = new MQPutMessageOptions();
queue.put(messageOut, pmo);
messageOutId = messageOut.messageId;
} finally {
closeQueue(queue);
}
// Receive
queue = openQueue(queueManager, syncQueueIn, MQC.MQOO_INPUT_AS_Q_DEF);
try {
MQMessage messageIn = new MQMessage();
messageIn.messageId = MQC.MQCI_NONE;
messageIn.correlationId = messageOutId;
MQGetMessageOptions gmo = new MQGetMessageOptions();
gmo.options = MQC.MQGMO_WAIT + MQC.MQMO_MATCH_CORREL_ID;
gmo.waitInterval = syncWaitInterval;
try {
queue.get(messageIn, gmo); ...
} catch (MQException mqe) {
if (mqe.reasonCode == 2033) {
log.error("Error during sending and recieving MQSeries messages: no answer", mqe);
} else {
log.error("Error during sending and recieving MQSeries messages", mqe);
throw mqe;
}
}
} finally {
closeQueue(queue);
}
} catch (MQException mqe) {
log.error("Error during sending and recieving MQSeries messages", mqe);
throw new CommunicationException("Error during MQSeries sync communication (submit and receive): " + mqe.getMessage());
} catch (IOException ioe) {
log.error("Error during sending and recieving MQSeries messages", ioe);
throw new CommunicationException("Error during MQSeries sync communication (submit and receive): " + ioe.getMessage());
} finally {
disconnect(queueManager);
}
|
Has anyone have an explanation for this kind of behavior???
I have to admit I'm a complete MQSeries newbie so any other comments on the code above would be nice.
Thanks in advance
Maarten |
|
Back to top |
|
 |
zpat |
Posted: Tue Jun 21, 2005 5:25 am Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
2033 means NO MSG AVAILABLE when the GET WAIT expired.
What is the wait interval? Why is this an error - is there a message on the queue or not?
BTW - don't open and close queues for each message - much more efficient to keep them open. |
|
Back to top |
|
 |
rebornspirit |
Posted: Tue Jun 21, 2005 5:35 am Post subject: |
|
|
Newbie
Joined: 21 Jun 2005 Posts: 8
|
The waitInterval is 15000.
But when I executed my test, I see him waiting on the 16th message for 15000 msecs, so in that time i check the MQSeries queue (in the explorer tool) to see if the message has arrived. The message has arrived with the correct correlation id, but the program is not retrieving it and this happens ONLY with every 16th message.
Getting nuts  |
|
Back to top |
|
 |
vennela |
Posted: Tue Jun 21, 2005 7:14 am Post subject: |
|
|
 Jedi Knight
Joined: 11 Aug 2002 Posts: 4055 Location: Hyderabad, India
|
Whoever is processing the message is not processing the 16th message right. |
|
Back to top |
|
 |
rebornspirit |
Posted: Tue Jun 21, 2005 11:47 am Post subject: |
|
|
Newbie
Joined: 21 Jun 2005 Posts: 8
|
Actually it is always the same method that is handling this queue message receival. The test method is placed in a loop because I noticed that sometimes the retrieval failed, after intensive testing it seems that every 16th message retrieval fails. So the statement that I would not be treating the 16th message wright would make NO sense because then all the other one would have to fail to because it is always the same test repeating over and over and over again.
The message on my in queue is correct, I checked the correlation id but it seems that it works for all tests in the loop until it reaches the 16th, or the next 16th elemen, I placed it in a loop of 500 tries and it was ALWAYSSS the 16th element, so 16, 32, 48, ... all the other messages worjk so why not this 16th ...
Has anyone have an explanation for this???? |
|
Back to top |
|
 |
fjb_saper |
Posted: Tue Jun 21, 2005 12:17 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Possibly the 16th message did not get committed...
check out the manuals: There is a number of reasons for the messages to show up in queue depth but not to be available (a get would return with 2033).
The most common reason is uncommited messages from a producer (sender).
Among the other usual suspects: expired messages.
Enjoy.  |
|
Back to top |
|
 |
rebornspirit |
Posted: Tue Jun 21, 2005 10:32 pm Post subject: |
|
|
Newbie
Joined: 21 Jun 2005 Posts: 8
|
I'm a newbie, so could you explain by what you mean with "did not get committed"? It is over and over again the same routine, so it would seem strange to me that only every 16the (16, 32, 48, ... ) message gets uncommitted? |
|
Back to top |
|
 |
rebornspirit |
Posted: Wed Jun 22, 2005 12:01 am Post subject: |
|
|
Newbie
Joined: 21 Jun 2005 Posts: 8
|
I took a look at the manual like you said but I don't see a solution here.
- Message is on the queue before time has expired
- The MQGMO_WAIT was specified to 15000
- The message that has been requested has the correct correlation id
- Requesting the message using MQC.MQMO_MATCH_CORREL_ID
- ??? I 'think' the unit of work was succesful, don't know how to see this????
Anyone with an idea??? |
|
Back to top |
|
 |
bower5932 |
Posted: Wed Jun 22, 2005 5:28 am Post subject: |
|
|
 Jedi Knight
Joined: 27 Aug 2001 Posts: 3023 Location: Dallas, TX, USA
|
Personally, I don't think this has anything to do with committed vs. uncommitted messages. I doubt you have anything in your program to not commit the 16th message. My guess is that every 16 messages, you are overwriting something (ie, your correlation or message id) and not getting a match. Do you have any tables, arrays, lists that are 16 large that might account for this? |
|
Back to top |
|
 |
rebornspirit |
Posted: Wed Jun 22, 2005 5:45 am Post subject: |
|
|
Newbie
Joined: 21 Jun 2005 Posts: 8
|
Nope, I took a look at my program and the MQSeries settings for anything that came close to the number 16 ... but no luck there
And I don't think my correlation id is being overwritten, because I have printed out the original messageId and this is the same with the correlationId I find on the message on the queue.
So I'm realy getting stuck with this problem, it ill propably be something stupid but ....
Maarten |
|
Back to top |
|
 |
jefflowrey |
Posted: Wed Jun 22, 2005 5:48 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
"Printed out"?
How?
As a string?
Or properly, as hex values. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
bower5932 |
Posted: Wed Jun 22, 2005 6:05 am Post subject: |
|
|
 Jedi Knight
Joined: 27 Aug 2001 Posts: 3023 Location: Dallas, TX, USA
|
I went out to:
http://www.developer.ibm.com/isv/tech/sampmq.html
and took the mqreqro.java and mqsrvro.java programs and stripped them down to do continuous puts/gets. I let the programs run for several hundred messages and didn't notice any messages not being received. |
|
Back to top |
|
 |
rebornspirit |
Posted: Wed Jun 22, 2005 7:36 am Post subject: |
|
|
Newbie
Joined: 21 Jun 2005 Posts: 8
|
Printing the correlation id's in a HEX format give's me the following
Every message that fails, for example
414D51204D5350325F44455620202020C042B44213906900
has the 90 (bold and inderlined) in it while the correlation id in the queue is
414D51204D5350325F44455620202020C042B442133F6900
Now this is what is do:
- a message is sent and received bu another program, its message id is being saved in a text field (have no ther choose here)
- in another program i retrieve it from that string (getBytes) and place it on the MQMessage that i sent back
So it seems that 16 has to do with the hex format ... i never worked before with hex stuff so if anyone can help out.
Thanks |
|
Back to top |
|
 |
bower5932 |
Posted: Wed Jun 22, 2005 7:47 am Post subject: |
|
|
 Jedi Knight
Joined: 27 Aug 2001 Posts: 3023 Location: Dallas, TX, USA
|
You really shouldn't treat the message and correlation id's as text. They are binary. I'd look at having your application change now since this will probably only cause you more trouble down the road. |
|
Back to top |
|
 |
rebornspirit |
Posted: Thu Jun 23, 2005 12:58 am Post subject: SOLVED |
|
|
Newbie
Joined: 21 Jun 2005 Posts: 8
|
For those who have the same problem and suggest the following if you MUST use a String format to transport the Hex Bytes:
- Convert Hex bytes to a String representation instead of just putting the bytes into a new String object
Code: |
int size = hexBytes.length;
StringBuffer buffer = new StringBuffer(size * 2);
for(int i = 0; i < size; i++) {
int myByte = hexBytes[i];
if (myByte < 0) {
myByte += 256;
}
String tmp = Integer.toHexString(myByte);
if (tmp.length() == 1) {
buffer.append("0");
}
buffer.append(tmp);
}
return buffer.toString();
|
- if ypu need to retrieve the hex data as bytes just convert the String representation you made before
Code: |
int size = hexString.length() / 2;
byte[] retValue = new byte[size];
String inString = hexString.toLowerCase();
for (int i = 0; i < size; i++) {
int index = i * 2;
int myByte = Integer.parseInt(inString.substring(index, index + 2), 16);
retValue[i] = (byte) myByte;
}
return retValue;
|
This works, but of you do the following:
mqmessage id hex bytes --> String --> String.getBytes --> mqmessage correlation id
Then it seems that something goes lost and you loose each16th message
Grtz
Maarten |
|
Back to top |
|
 |
|