Author |
Message
|
dipankar |
Posted: Tue Jun 19, 2007 1:43 am Post subject: Dequeued Failure Message |
|
|
Disciple
Joined: 03 Feb 2005 Posts: 171
|
Hi,
Environment:AIX, WBI MB 5, CSD 06, MQ 5.3 CSD 12.
I am getting sometimes Dequeued Failure Message exception. Please consider the following message flow --
Code: |
MQInput Node ----> Processing Node ---> MQOutput Node |
The error handler is connected to both catch & fail terminal of MQInput Node.
Error handler:
Quote: |
trycatch node(try terminal) ---> processing node(logging) ---> MQOutput
trycatch node (catch terminal) --->trace node --->MqOutput |
Within the trace node I write ${ExceptionList} only.
What I know ---
When any message fails in main flow, it will go to Error Handler via catch terminal of MQInput node. Now if error handler(connected to try terminal) itself fails to process it will go to catch terminal of trycatch node. Now if it again fails to process, it will go back to MQInput node.
Now this time message will go to Error handler through failure terminal and again roll back to MQInput node. This time I will get Dequeue failure message exception.
Please correct me if I am wrong.
As I have mentioned only {ExceptionList}, I am not finding any reason of dequeued failure message.
Most important thing, I am getting the text
Quote: |
'Dequeued failed message. Propagating a message to the failure terminal' |
into the logging table (logging node connected with try terminal of TryCatch node).
If I put the same message again into Input queue, it is getting processed successfully. As this is in production system, I am unable to take trace.
I guess somehow MQinput node is itself creating the dequeued message. Somehow backout count is getting more than 1.
Could anyone tell me how this exception is occurring? I am looking for your valuable inputs. Thanks in advance. _________________ Regards |
|
Back to top |
|
 |
jbanoop |
Posted: Tue Jun 19, 2007 7:07 am Post subject: |
|
|
Chevalier
Joined: 17 Sep 2005 Posts: 401 Location: SC
|
The message you are getting
Quote: |
'Dequeued failed message. Propagating a message to the failure terminal' |
is the exception message that is given by the MQInput node when it goes through its failure terminal.
Ideally your error handler should not fail the first time ..ie when the message after the exception goes through the catch terminal of the input node to the error handler, you will have the correct exception list (the actul cause of what caused the failure in the flow). Error handlers should be designed in such a way that it does not fail when the flow fails.
The moment you roll back again to the MQinput node, the exception list would change to 'Dequeuing failed message' which is what the MQInput node would do.
So my advice is instead of connecting both catch and failure terminals , you should connect only the catch to the error handler which could log the error (file based logging is the safest in an exception scenario) and then throw the eception again to facilitate rollback of the transaction (if indeed you need it) . I would try to leave the failure terminal of the MQInput node untouched as much as I could .. but it depends on your requirements.
Hope it helped.
Anoop |
|
Back to top |
|
 |
dipankar |
Posted: Tue Jun 19, 2007 7:17 am Post subject: |
|
|
Disciple
Joined: 03 Feb 2005 Posts: 171
|
Hi Anoop,
Thanks a lot.
I have used TryCatch Node in error handler. If somohow try terminal fails, catch terminal cannot be failed. Because I am only used trace node and I have written {ExceptionList}only in trace node. Another point I am not getting any trace file mentioned in the trace node. So obviously, message is not going through this way.
Hope you got my point. _________________ Regards |
|
Back to top |
|
 |
jbanoop |
Posted: Tue Jun 19, 2007 9:04 am Post subject: |
|
|
Chevalier
Joined: 17 Sep 2005 Posts: 401 Location: SC
|
The write to the trace file may be failing. Check to see if the path is correct and the file is accesable for writing to the broker user id.
check the syslog for errors regarding the trace node.
maybe you can try using the trace commands to actually trace the path of execution.
Also , are you throwing from the error handler to roll back the whole transaction once the error logging has been completed ? |
|
Back to top |
|
 |
dipankar |
Posted: Thu Jun 21, 2007 1:54 am Post subject: |
|
|
Disciple
Joined: 03 Feb 2005 Posts: 171
|
Hi Anoop,
Quote: |
The write to the trace file may be failing. Check to see if the path is correct and the file is accesable for writing to the broker user id. |
path is correct. Permission is also okay. Because most of cases, that trace file is creating.
I am getting sometimes this dequeued failure message, not all time. If I again put that input message, it is getting processed successfully.
Quote: |
Also , are you throwing from the error handler to roll back the whole transaction once the error logging has been completed ? |
No.
As per my understanding, it should not happen as per message flow design. This might be some cofiguration related problem.
Thanks _________________ Regards |
|
Back to top |
|
 |
wbi_telecom |
Posted: Thu Jun 21, 2007 12:20 pm Post subject: |
|
|
 Disciple
Joined: 15 Feb 2006 Posts: 188 Location: Harrisburg, PA
|
Are you sure you have only one instance of the flow deployed on the broker? It may happen that you have an older version deployed that's accounting for the error and then your correct version is giving you the results.
Cheers, |
|
Back to top |
|
 |
dipankar |
Posted: Fri Jun 22, 2007 4:13 am Post subject: |
|
|
Disciple
Joined: 03 Feb 2005 Posts: 171
|
Hi,
Thanks for your response. Open Input count of the input queue is 1. This means only one instance of message flow is running. _________________ Regards |
|
Back to top |
|
 |
|