| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| WMQIB V2.1 Retry Loop |
« View previous topic :: View next topic » |
| Author |
Message
|
| dkeister |
 Posted: Mon Mar 07, 2005 2:59 pm Post subject: WMQIB V2.1 Retry Loop |
 |
|
Disciple
Joined: 25 Mar 2002
Posts: 184
Location: Purchase, New York
|
I 'think' I understand the failure processing sequence of an MQInput node.
My situation.
- Message flow has Out and Catch terminal wired
- Dead letter queue defined but no backout count/queue
A 'bad' message is put to the queue and it ends up on the DLQ as expected.
The 'bad' message is put to the queue a second time and it ends up in a retry loop. At least that is what I think is going on. I am remote from the actual system.
Any ideas?
Dean Keister |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Mon Mar 07, 2005 3:09 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Add a throw node to the end of the flow on the catch terminal.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| dkeister |
| Posted: Tue Mar 08, 2005 6:14 am Post subject: |
|
|
Disciple
Joined: 25 Mar 2002
Posts: 184
Location: Purchase, New York
|
Not sure that will help. I thought that if neither the catch node nor the failure node is wired, the message would end up on the DLQ. Is this right?
I have a common subflow I use on the catch node. It decodes the error and puts it into a message which then is put to a queue being processed by a second flow that takes the message and sends an email (the sendmail flow is common across several applications) so I have first failure data capture. That way, in production, I get an email if there is any failure.
So, I don't think that the catch leg is ever executed. If I have it right, if there happens to be a problem on that leg (like the sendmail queue is full) the message should go to the SYSTEM.DEAD.LETTER.QUEUE with no need to wire a throw node. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Mar 08, 2005 11:14 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I believe that if the Catch path completes successfully, then the message will NOT have any sort of backout processing occur - like put it to the DLQ. The catch path completing would indicate a success on the MQInput, and thus a commit of the Get.
I know that if you don't rethrow out of the Catch flow, then the normal system logging of errors won't occur. So in cases where the message would normally pass to Fail after Catch, you won't get errors that tell you why it went to Catch in the first place.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| dkeister |
| Posted: Tue Mar 08, 2005 11:58 am Post subject: |
|
|
Disciple
Joined: 25 Mar 2002
Posts: 184
Location: Purchase, New York
|
I know if Catch completes successfully there is no backout processing since everything completes successfully and the GET is committed.
I think that if the Catch fails, the message should ultimately be backed out and sent to the DLQ, the Backout Q or thrown away.
I think that if I wire a TryCatch to the catch node with my 'normal failure processing' on the Try leg and wire a throw node to the catch terminal I would get errors that help identify the problem on the Catch processing (I'm confusing myself).
However, I think that if the Catch leg of the input node fails, a message should end up on the DLQ rather than enter a retry loop. |
|
| 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
|
|
|
|
