| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MQGET node in Message Broker v6, 2 attempts and timeout |
« View previous topic :: View next topic » |
| Author |
Message
|
| Broady |
 Posted: Tue Aug 05, 2008 4:45 am Post subject: MQGET node in Message Broker v6, 2 attempts and timeout |
 |
|
Novice
Joined: 16 Apr 2004
Posts: 23
Location: Halifax, West Yorkshire, England
|
We are running version 6.0.2 WBIMB Message Broker and version 6.0 of MQ - with a flow that uses the MQGET node to read a queue using the corellation id.
Properties of the MQGET node are:-
Transaction Mode = 'Yes'
Wait Interval = 1000ms
Minimum message buffer size 4kb
In normal circumstances, in a trace we get the following;
MQGetNode 'O_RET_OUTBOUND_PAYMT_TERM.EAX_SERVICE_RESPONSE_SUB.EAX_SERVICE_RESPONSE_GET_CONTEXT_SUB.MQGet' has made 2 attempt(s) at calling MQGET() to read queue ''EAS.ORCH_CTX.STORE_1'' of queue manager ''QGFIE804''. The last call returned with MQ completion code 0 and reason code 0.
If the call(s) failed (returned with a non-zero return code), check the error codes and the other information provided to determine the cause of the failure and take any action necessary to resolve the problem. Possible causes include incorrect queue name, queue not readable, and message too large.
2008-08-05 11:25:33.159778 9010 UserTrace BIP6060I: Parser type ''Properties'' created on behalf of node 'O_RET_OUTBOUND_PAYMT_TERM.EAX_SERVICE_RESPONSE_SUB.EAX_SERVICE_RESPONSE_GET_CONTEXT_SUB.MQGet' to handle portion of incoming message of length 0 bytes beginning at offset '0'.
The MQGET seems to make 2 attempts to read the queue.
Could someone explain why there are 2 attempts ?
In circumstance where we are processing 10 transactions per second for 1 minute, 99.9% get the above - in certain circumstances, we are getting the following;
2008-08-05 11:25:32.077041 9010 UserTrace BIP2657I: MQGetNode 'O_RET_OUTBOUND_PAYMT_TERM.EAX_SERVICE_RESPONSE_SUB.EAX_SERVICE_RESPONSE_GET_CONTEXT_SUB.MQGet' has completed its MQGET() call. The returned MQ codes are: MQCC=2, MQRC=2033.
MQGetNode 'O_RET_OUTBOUND_PAYMT_TERM.EAX_SERVICE_RESPONSE_SUB.EAX_SERVICE_RESPONSE_GET_CONTEXT_SUB.MQGet' has made 1 attempt(s) at calling MQGET() to read queue ''EAS.ORCH_CTX.STORE_1'' of queue manager ''QGFIE804''. The last call returned with MQ completion code 2 and reason code 2033.
If the call(s) failed (returned with a non-zero return code), check the error codes and the other information provided to determine the cause of the failure and take any action necessary to resolve the problem. Possible causes include incorrect queue name, queue not readable, and message too large.
2008-08-05 11:25:32.077220 9010 UserTrace BIP2658I: MQGetNode 'O_RET_OUTBOUND_PAYMT_TERM.EAX_SERVICE_RESPONSE_SUB.EAX_SERVICE_RESPONSE_GET_CONTEXT_SUB.MQGet' is propagating a message to the 'No Message' Terminal.
None
Could someone explain why this happens ?
We guess is that it simply times out due to the volume, but I don't know why the other calls show 2 attempts, and of course I am unsure of the solution to such perfomance issue.
Many thanks
_________________
Alan Broadbent |
|
| Back to top |
|
 |
| zpat |
| Posted: Tue Aug 05, 2008 4:58 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5867
Location: UK
|
It might be doing an 2 MQGETs in order to obtain the message length first and then a suitable size buffer for the destructive get.
Try increasing the wait time limit to avoid the 2033. |
|
| Back to top |
|
|
| Broady |
| Posted: Tue Aug 05, 2008 8:04 am Post subject: |
|
|
Novice
Joined: 16 Apr 2004
Posts: 23
Location: Halifax, West Yorkshire, England
|
Thanks for the reply.
That is food for thought.
We now think the issue is a corrputed Corellation id. It appears the last byte has been modified from a "20" i.e. space to a "00" i.e. null.
Ever seen this happen?
Cheers.
_________________
Alan Broadbent |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Aug 05, 2008 11:32 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5867
Location: UK
|
What program sets the Correlid?
Perhaps it is handling the field's data incorrectly when moving the Msgid to the Correlid.
It's not likely to be a problem in IBM code.
Last edited by zpat on Wed Aug 06, 2008 2:08 am; edited 1 time in total |
|
| Back to top |
|
|
| Broady |
| Posted: Wed Aug 06, 2008 12:39 am Post subject: |
|
|
Novice
Joined: 16 Apr 2004
Posts: 23
Location: Halifax, West Yorkshire, England
|
Thanks for the reply.
We are leaving the investigation to the team that are providing the Corellation id; they are performing compares in/out etc.
I just wanted to cover off any known bug that may have caused this; I'm happy to close this topic off.
Thanks again for your time.
Cheers.
_________________
Alan Broadbent |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
