| Author |
Message
|
| indu30111986 |
 Posted: Wed Apr 04, 2012 4:53 am Post subject: Need to set infinite retry in case of failure |
 |
|
Novice
Joined: 15 Nov 2011
Posts: 22
|
My scenario is when i a message is sent to the input queue my compute node does some manipulations and sends the output to multiple queues.If any of the queues is down or the message is not sent to any of the output queue due to some reason the whole transaction has to be rolled back and the message should not be sent to other queues and the message should be retried until the message is sent to all the queues.Moreover the message from the input queue should be persistent.
I have implemented this using a MQinput node--->compute-->mqoutput
in the MQ input node with transaction as 'Yes'.
Please let me how know to implement this |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed Apr 04, 2012 5:01 am Post subject: Re: Need to set infinite retry in case of failure |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| indu30111986 wrote: |
| Please let me how know to implement this |
The first and most obvious point is "are you serious?" 
You want infinite retries. Infinite. You want this to bang on round and round forever? I understand you want it to retry & possibly for a large number of times, but at some point wouldn't it be a really good idea if it stopped trying and flagged an error so someone knew there was a problem putting to one of the queues and fixed it?
The second point is you implement this as you've implemented this. Charitably assuming you've tried this and it ran once before stopping, you've probably not filled the imput queue backout count with 9s.
Not infinite but close enough. Too close IMHO.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| indu30111986 |
| Posted: Wed Apr 04, 2012 5:12 am Post subject: |
|
|
Novice
Joined: 15 Nov 2011
Posts: 22
|
i am working on Type B messages.Those messages are to be delivered sequentially and should be message should not be lost.
So we have to retry until the message is sent to the output queues without any error.
Can u suggest any other idea |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Apr 04, 2012 5:27 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| indu30111986 wrote: |
| i am working on Type B messages. |
Congratulations. I have no clue what those are but I don't think it's relevant to this post.
| indu30111986 wrote: |
| Those messages are to be delivered sequentially and should be message should not be lost. |
The problems of message affinity are well known and often discussed in here.
| indu30111986 wrote: |
| So we have to retry until the message is sent to the output queues without any error. |
Listen to what you're saying - you don't want to retry until the message is sent without error. Suppose one of the targets has a hardware fault that requires days to fix? Or it's site is subject to a disaster & has to be recovered? Even if it's as simple as the reading application gone down and the target queue has filled up, do you really want your flow going round and round until someone notices the application is down and fixes it? You're entirely reliant on this target are having sufficient monitoring to notice that the application is down and/or the queue is full.
That's a risk in your design your stakeholders need to be aware of.
| indu30111986 wrote: |
| Can u suggest any other idea |
Your requirement is not to be retrying indefinitely. Your requirement is to deliver messages in sequence with no gaps. A failure should result in an error being raised, the failed message being held and no further messages being delivered until that one has been. Depending on how wide the affinity is, WMQ's sequencing facilities may be of aid.
Welcome to the hell of message affinity. Enjoy your stay.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Apr 04, 2012 5:32 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
If you fancy something quick and dirty, you could stick with your current design & add a leg to your flow with a FlowControl node. The Second leg of this node is your current processing unchanged. The First leg has a Filter node that checks the backout count of the message. If it's non-zero an Email node emails the WMB support team, all the support teams for all of your possible targets & your stakeholder to notify them there's a problem with delivery. One of them will fix it.
Other, possibly worse, solutions are undoubtably possible. But I doubt it.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| McueMart |
| Posted: Wed Apr 04, 2012 6:49 am Post subject: |
|
|
Chevalier
Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere
|
| Quote: |
| If it's non-zero an Email node emails the WMB support team |
Im sure them getting an email every 1 second will result in the issue being resolved rather quickly  |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Apr 04, 2012 7:08 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| McueMart wrote: |
| Quote: |
| If it's non-zero an Email node emails the WMB support team |
Im sure them getting an email every 1 second will result in the issue being resolved rather quickly |
I saw that as one of the key points of my design; it's the electronic equivalent of standing on a desk, stamping your feet, screaming and waveing.
If nothing else, the support team for the email server will notice there's an issue..... 
Who says spam has no value?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Wed Apr 04, 2012 9:36 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| Vitor wrote: |
If nothing else, the support team for the email server will notice there's an issue.....
|
The will respond by blocking both the sender and receiver.
Resulting in...
The Broker Support team sleeping soundly in their beds while the system crashes and burns.
{been there. Seen it happen in reality. The emails took down the corporate Exchange server. The PHB's were not very happy. Not happy at all.}
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Apr 04, 2012 10:28 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| smdavies99 wrote: |
| The Broker Support team sleeping soundly in their beds while the system crashes and burns. |
So my design has other advantages (from a broker perspective)? I'm clearly having a good day...
As I said originally, a worse solution may be possible but is unlikely!
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| er_pankajgupta84 |
| Posted: Wed Apr 04, 2012 11:03 am Post subject: |
|
|
Master
Joined: 14 Nov 2008
Posts: 203
Location: charlotte,NC, USA
|
Another complex solution to the original problem could be (Assuming indu30111986 cannot use Sequencing nodes)
1. Try for a finite number of tries (Configurable) and then raise a notification to the support team and stop the flow programatically.
2. Have another flow (timer driven) which periodically start the flow programatically after checking its current status.
But what exceptions to should raise these conditions are again questionable. |
|
| Back to top |
|
|
|
|
