| Author |
Message
|
| alewis |
 Posted: Thu Nov 16, 2006 10:39 am Post subject: Message rollback |
 |
|
Novice
Joined: 20 Aug 2006
Posts: 13
|
The scenario is MQInput --> Compute ---> HttpRequest --->Compute-->MQOutput
If the HttpRequest fails i.e communication to web services fails, I should be retrying till the threshold count reaches a defined threshold limit. When the threshold limit is breached, it is required that the message be returned to the MQInput queue and not the backout queue or the dead letter queue and the message flow stopped.
Can we send the message back to the same position in the queue referred by the MQInput node and not the last message in the input queue. |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Thu Nov 16, 2006 10:45 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Yes.
Read about Backout Threshould and Backout Retry Queue.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| alewis |
| Posted: Thu Nov 16, 2006 10:55 am Post subject: |
|
|
Novice
Joined: 20 Aug 2006
Posts: 13
|
I know how to enter the retry mode but when the threshold limit is reached, the broker does the following:
Checks to see if the backout queue is defined and delivers the message
If the backout count is not defined checks if the DLQ is defined as sends the message to the DLQ
If neither is defined it continues to retry the message.
The problem that I have is when the threshold count is reached, the message passes through the failure terminal and I have to stop the message flow. How do I send the message back to the MQInput queue and that too in the same order in which it was picked. |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Thu Nov 16, 2006 12:01 pm Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
So, if you want to try this message forever, then you could catch the exception and put it in the HTTPRequest again. You might consider a way to stop this infinite loop...
_________________
Joseph
Administrator - IBM WebSphere MQ (WMQ) V6.0, IBM WebSphere Message Broker (WMB) V6.1 & V6.0
Solution Designer - WMQ V6.0
Solution Developer - WMB V6.1 & V6.0, WMQ V5.3 |
|
| Back to top |
|
|
| alewis |
| Posted: Thu Nov 16, 2006 2:04 pm Post subject: |
|
|
Novice
Joined: 20 Aug 2006
Posts: 13
|
| It will not enter into an infinite loop as in the catch/failure path I would check the backout count and stop the message flow if the backcount count has exceeded the threshold limit |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Nov 16, 2006 5:43 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Let's be clear.
When a message flow throws an exception that is NOT caught at the MQInput node's catch terminal (perhaps because there is a throw node at the end of whatever is connected to the catch terminal), then the MQInput node performs a normal MQBACK.
This means that the message is restored to it's original position on the queue - since it essentially never left - and is the first available message for getting.
BEFORE the MQInput node performs the MQBACK, it compares the Backout Count on the Message with the Backout Threshold on the Queue. If the Backout Count is greater than the Backout Threshold AND there is a Backout Queue defined - then the MQInput node tries to put the message to the Backout Queue (defined on the input queue). If it can't do that, then the message goes to the DLQ. If it can't go to the DLQ -AND the message is persistent, then everything rapidly goes somewhere in a handbasket.
If the message is non-persistent, then the MQInput node will discard it.
The salient feature here is the Backout Threshold.
You can set this very very high.
If you don't define a Backout Queue, then the MQInput node will NEVER stop backing out a persistent message.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
