| Author |
Message
|
| wmbv7newbie |
 Posted: Thu Jul 30, 2015 2:16 am Post subject: WMB V8 - Dequeued failed message |
 |
|
Centurion
Joined: 13 May 2014
Posts: 121
|
Hi,
I have a flow which occasionally gives me the below exception in higher environments (Dev and QA at the moment) -
| Quote: |
| <Number>2652</Number><Text>Dequeued failed message. Propagating a message to the failure terminal</Text> |
Although when I run the same request in local, it processes successfully. The flow is quite simple -
MQInput node -> compute -> subflow with 3 webservice calls -> compute response -> MQOutput
All requests and responses are XML. Webservice response is JSON which we convert to xml in compute. There are no loops, but I have a few PROPAGATE statements with RETURN FALSE. All failure terminals are connected to our Exception Handling subflow, which logs message to an error queue.
Since, I am not able to replicate the issue in local, I dont know how to debug. We dont have access to debugger in higher environments and neither can we deploy the changed code with trace etc. without approval.
Can someone give a few hints about the scenarios when this exception occurs.
Thanks |
|
| Back to top |
|
 |
| smdavies99 |
| Posted: Thu Jul 30, 2015 2:44 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
does your error handling (connected to the Catch Terminal on the MQInput Node) throw an exception? i.e. RETHROW it
does your MQ Queue have a BOQ defined?
does the problem message end up on the BOQ?
could there some sort of timeout with one or more of
the WebService calls?
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| wmbv7newbie |
| Posted: Thu Jul 30, 2015 2:58 am Post subject: |
|
|
Centurion
Joined: 13 May 2014
Posts: 121
|
| Quote: |
| does your error handling (connected to the Catch Terminal on the MQInput Node) throw an exception? i.e. RETHROW it |
- No. The error handler writes the dequeued exception to the queue (with the payload) and through the out terminal connected to it, we create an xml response. The flow completes throught that out terminal and writes the response to another queue.
| Quote: |
| does your MQ Queue have a BOQ defined? |
- Yes
| Quote: |
| does the problem message end up on the BOQ? |
- No
| Quote: |
could there some sort of timeout with one or more of
the WebService calls? |
- none defined. Those webservices respond pretty quickly as we have had performance testing with all applications.
Thsi exception is intermittent. Like, once in a day. |
|
| Back to top |
|
|
| Armageddon123 |
| Posted: Thu Jul 30, 2015 9:42 am Post subject: |
|
|
Acolyte
Joined: 11 Feb 2014
Posts: 61
|
| have you looked at the MQ/broker logs for MQ errors similar to 'log size full'. ? . There must be one similar to that. |
|
| Back to top |
|
|
| wmbv7newbie |
| Posted: Thu Jul 30, 2015 9:09 pm Post subject: |
|
|
Centurion
Joined: 13 May 2014
Posts: 121
|
Thanks for your suggestions, everyone.
We noticed that there were two versions of the same application deployed in the EGs. Both the versions have same queues etc.
After we removed the obsolete version, the flow seems to work good.
Our conclusion is that the broker was confused which app to use since both had same input queue to write the message and hence, the write was failing. If anyone has any other conclusions, please suggest.
Thanks again! |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Thu Jul 30, 2015 10:38 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| wmbv7newbie wrote: |
Our conclusion is that the broker was confused which app to use since both had same input queue to write the message and hence, the write was failing. If anyone has any other conclusions, please suggest.
! |
not quite right
This is MQ working as designed AFAIK. To IPPROCS on the same queue will result in a form of round robin scheduling. (I'll leave it to the MQ internals experts to comment if they see the need). One message is read by process 1, the next by process 2 the next by process 1 etc etc.
I'm glad you found the issue.
A good tip is to use MQExplorer ans look at the ipprocs for any queue. The showning the queue status will reveal what process ID's have issued the ipprocs.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
|
|
