ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » Controlling the number of retries

Post new topic  Reply to topic
 Controlling the number of retries « View previous topic :: View next topic » 
Author Message
WBI_user
PostPosted: Fri Jun 29, 2007 12:41 pm    Post subject: Controlling the number of retries Reply with quote

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
View user's profile Send private message
jefflowrey
PostPosted: Fri Jun 29, 2007 3:35 pm    Post subject: Reply with quote

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
View user's profile Send private message
jbanoop
PostPosted: Fri Jun 29, 2007 6:20 pm    Post subject: Reply with quote

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
View user's profile Send private message Yahoo Messenger
WBI_user
PostPosted: Tue Jul 03, 2007 6:36 am    Post subject: Reply with quote

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
View user's profile Send private message
jbanoop
PostPosted: Tue Jul 03, 2007 8:47 am    Post subject: Reply with quote

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
View user's profile Send private message Yahoo Messenger
jefflowrey
PostPosted: Tue Jul 03, 2007 9:11 am    Post subject: Reply with quote

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
View user's profile Send private message
elvis_gn
PostPosted: Tue Jul 03, 2007 9:27 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
jbanoop
PostPosted: Tue Jul 03, 2007 9:54 am    Post subject: Reply with quote

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
View user's profile Send private message Yahoo Messenger
jefflowrey
PostPosted: Tue Jul 03, 2007 9:56 am    Post subject: Reply with quote

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
View user's profile Send private message
elvis_gn
PostPosted: Tue Jul 03, 2007 10:01 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
jbanoop
PostPosted: Tue Jul 03, 2007 10:08 am    Post subject: Reply with quote

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
View user's profile Send private message Yahoo Messenger
elvis_gn
PostPosted: Tue Jul 03, 2007 10:31 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
jefflowrey
PostPosted: Tue Jul 03, 2007 10:35 am    Post subject: Reply with quote

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
View user's profile Send private message
WBI_user
PostPosted: Tue Jul 03, 2007 11:01 am    Post subject: Reply with quote

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
View user's profile Send private message
jbanoop
PostPosted: Wed Jul 04, 2007 7:15 am    Post subject: Reply with quote

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
View user's profile Send private message Yahoo Messenger
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » Controlling the number of retries
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.