| Author |
Message
|
| WBI_user |
 Posted: Fri Jun 29, 2007 12:41 pm Post subject: Controlling the number of retries |
 |
|
Partisan
Joined: 07 Aug 2001
Posts: 386
|
I have the requirement to develop an exception handling message subflow which can be re-used by ogher message flows. All the message flows using the subflow are transactional. I am stuck on the rery requirement which I hope someone can help.
This requirement is to control the number of tryies based on the error type.
I know the number of retry is set by backout threshold on the input queue. So What I am doing now is throwing an exception at th end of the catch flow to cause the message and any resource update by the main flow to roll back. The rolled back message is then pickup again and retried up to the count specified in the backout threshold. However there are a number of error conditons which we want to retry less or more times than what is specified in the vbackout threshold. This is what I am stuck on. Any suggestions ? |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Fri Jun 29, 2007 3:35 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Well. It's easy to cause the message to be rolled back fewer times than the backout count. Just put it to the backout queue yourself when you're ready.
It's... harder... to cause it be rolled back more times than the backout count. One could, conceivably, do stuff with PCF messages to temporarily increase the backout count.
Or one could, say... add an extra out terminal (perhaps called "retry") to the subflow. Then instead of exiting the subflow by throwing an error, one would exit it to the retry terminal - which would be wired back to the main loop of the flow for retry.
But it gets messy.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| jbanoop |
| Posted: Fri Jun 29, 2007 6:20 pm Post subject: |
|
|
Chevalier
Joined: 17 Sep 2005
Posts: 401
Location: SC
|
| but i guess for the first case when the retry flow puts the message in the backout queue the flow would end successfully causing a commit of whatever was successfully done before the error occurred. |
|
| Back to top |
|
|
| WBI_user |
| Posted: Tue Jul 03, 2007 6:36 am Post subject: |
|
|
Partisan
Joined: 07 Aug 2001
Posts: 386
|
Thanks for the quick response.
I have a scenario here which I need some help on.
For example, there are 3 types pf errors with the retry requirement as follow
Type A (error_A) no retry
Type B (error_B) retry once
Type C(error_C) retry 2 times
My test flow is
MQINPUT - DB (update) - COMPUTE1 - MQOUTPUT
COMPUTE1 detects the error (error_A)
If I connect the failure terminal of COMPUTE1 to an MQOUTPUT node (FailureQ), the message goes there as expected. So there is no retry as what I want. However update to the DB is comitted. This is not what I want.
If I do not connect the failure terminal of COMPUTE1, the message get rolled back and DB update also rolled back. Now the message is retried with a backout count of 1. Yes, I can use a filter node to say if backout is >= 1 , pass the message to a BACKOUT queue. But this will kill the retries for error_B and error_C. So I need to have the condition in the filter node to say , if it is error_A and the backOutCount is >=1, then pass it to BACKOUT Q. This means that I have to remember the failure across the two message. This is consider rememebr of state and I know that I can use a queue or DB to do. But I only want to do this if there is no other way of doing it. So I am looking for suggestions.
Another question is , is there anyway to ask the broker to commit or rolled the message flow from a node within the flow ? If there is, then I can ask the broker to roll back before I pass the message to the failure terminal. |
|
| Back to top |
|
|
| jbanoop |
| Posted: Tue Jul 03, 2007 8:47 am Post subject: |
|
|
Chevalier
Joined: 17 Sep 2005
Posts: 401
Location: SC
|
| I dont think you can do it the way you want but then i may be wrong. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Jul 03, 2007 9:11 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You can, maybe, use alias queues for the different message types and set different bothresh on the qalias.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| elvis_gn |
| Posted: Tue Jul 03, 2007 9:27 am Post subject: |
|
|
Padawan
Joined: 08 Oct 2004
Posts: 1905
Location: Dubai
|
Hi WBI_user,
| WBI_user wrote: |
My test flow is
MQINPUT - DB (update) - COMPUTE1 - MQOUTPUT
COMPUTE1 detects the error (error_A)
If I connect the failure terminal of COMPUTE1 to an MQOUTPUT node (FailureQ), the message goes there as expected. So there is no retry as what I want. However update to the DB is comitted. This is not what I want.
If I do not connect the failure terminal of COMPUTE1, the message get rolled back and DB update also rolled back. Now the message is retried with a backout count of 1. Yes, I can use a filter node to say if backout is >= 1 , pass the message to a BACKOUT queue. But this will kill the retries for error_B and error_C. So I need to have the condition in the filter node to say , if it is error_A and the backOutCount is >=1, then pass it to BACKOUT Q. This means that I have to remember the failure across the two message. This is consider rememebr of state and I know that I can use a queue or DB to do. But I only want to do this if there is no other way of doing it. So I am looking for suggestions. |
Maybe I understood you wrong, but if you catch your exception at the MQInput node using a compute, you will not have the backout count of 1 and be able to recognize that it's error_A.
If it's not error_A, throw it again to retry...catch the second time with backout 1 and know that it's error_B, else throw again and try a third time...
Regards. |
|
| Back to top |
|
|
| jbanoop |
| Posted: Tue Jul 03, 2007 9:54 am Post subject: |
|
|
Chevalier
Joined: 17 Sep 2005
Posts: 401
Location: SC
|
WBI_user wants to rollback the transaction if it is error_A the first time he encounters it. This is easy I guess, by throwing out of the error handler causing a full rollback. However in this case, the message will get resubmitted with a backout count of 1. He would however not want to retry the same since it was rolled back because of error_A, but would not have that information to make the decision in the filter node.
Basically he wants to roll back the transaction completely using the default transaction rollback mechanism of MB and also wants to be able to decide when the message is resubmitted, the cause of the rollback and depending on that decide whether to go ahead or not.
Atleast that is what i could make out of it. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Jul 03, 2007 9:56 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| jbanoop wrote: |
WBI_user wants to rollback the transaction if it is error_A the first time he encounters it. This is easy I guess, by throwing out of the error handler causing a full rollback. However in this case, the message will get resubmitted with a backout count of 1. He would however not want to retry the same since it was rolled back because of error_A, but would not have that information to make the decision in the filter node.
Basically he wants to roll back the transaction completely using the default transaction rollback mechanism of MB and also wants to be able to decide when the message is resubmitted, the cause of the rollback and depending on that decide whether to go ahead or not. |
Use a flow against the backout queue, to resubmit, and set the bothresh (of the input/main queue) to 1...
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| elvis_gn |
| Posted: Tue Jul 03, 2007 10:01 am Post subject: |
|
|
Padawan
Joined: 08 Oct 2004
Posts: 1905
Location: Dubai
|
Hi jbanoop,
| jbanoop wrote: |
WBI_user wants to rollback the transaction if it is error_A the first time he encounters it. This is easy I guess, by throwing out of the error handler causing a full rollback. However in this case, the message will get resubmitted with a backout count of 1. He would however not want to retry the same since it was rolled back because of error_A, but would not have that information to make the decision in the filter node.
Basically he wants to roll back the transaction completely using the default transaction rollback mechanism of MB and also wants to be able to decide when the message is resubmitted, the cause of the rollback and depending on that decide whether to go ahead or not. |
So if it's error_A, don't throw it back after you've caught it at the MQInput node, simply do a return false in the error handling compute node....that should roll back db, and not retry for error_A, and if its not error_A, throw again...
Regards. |
|
| Back to top |
|
|
| jbanoop |
| Posted: Tue Jul 03, 2007 10:08 am Post subject: |
|
|
Chevalier
Joined: 17 Sep 2005
Posts: 401
Location: SC
|
but then i thought a return false would still commit the things already done by the flow till then (till before the error occured).. it would not rollback.
Anyway provided this is the case too, how would he be able to handle the error_B scenario ? |
|
| Back to top |
|
|
| elvis_gn |
| Posted: Tue Jul 03, 2007 10:31 am Post subject: |
|
|
Padawan
Joined: 08 Oct 2004
Posts: 1905
Location: Dubai
|
Hi jbanoop,
| jbanoop wrote: |
| but then i thought a return false would still commit the things already done by the flow till then (till before the error occured).. it would not rollback. |
The return false is in the error path, that should have a different transaction...the transaction in the flow path has been rolled back due to the throw in the compute after the Db update....I hope jeff agrees 
| jbanoop wrote: |
| Anyway provided this is the case too, how would he be able to handle the error_B scenario ? |
On catching the error in the error path, check the backOut count, if the count is 0 then it can be error A, B or C....if A return false, knowing that it's not error_A, throw it. It will be returned for retry with count 1...now it can be error B or C....if B, return false else throw again. It will be returned with count 2...now it can be only error C..return false.
Regards. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Jul 03, 2007 10:35 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Rollback doesn't happen until after the throw terminal has been completely processed... as far as I know.
Neither does backout.
It's probably best to go to DevWorks and review the article on Bulletproofing Flows - I'm pretty sure it's by Tim Dunn.
Then look at processing messages in the backout queue, rather than trying to process messages in the main flow.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| WBI_user |
| Posted: Tue Jul 03, 2007 11:01 am Post subject: |
|
|
Partisan
Joined: 07 Aug 2001
Posts: 386
|
I have taken the path of passing information between messages within the same flow while I am waiting for other suggestion.
I used a share variable to save the error type of the first exception
My test flow is now
MQINPUT - filter - DB (update) - COMPUTE1 - MQOUTPUT
the ESQL in the filter node is
--====
IF ErrorType = 'A' AND Root.MQMD.BackoutCount >= 1 THEN
SET ErrorType = ' ';
RETURN FALSE;
--=====
Where ErrorType is a shared variable
When it is False, I will pass the message to the BACKOUT queue (i.e. no more retry)
COMPUTE1 will set ErrorType='A' when it detects Error_A.
I found out that we have to let the message rolled back (I think this is part of the roll back processing of the broker) before the broker can successfully roll back the DB update (please correct me if I am wrong).
I think I can get it work this way. I'll continue my test with error_B and error_C and update you later.
I am still looking for better suggestions. |
|
| Back to top |
|
|
| jbanoop |
| Posted: Wed Jul 04, 2007 7:15 am Post subject: |
|
|
Chevalier
Joined: 17 Sep 2005
Posts: 401
Location: SC
|
| What you are doing currently seems a good way to go ahead with it but I would wait for the comment of others as well. |
|
| Back to top |
|
|
|
|
