| Author |
Message
|
| sai kumar adduri |
 Posted: Tue Nov 19, 2013 6:12 am Post subject: Timer controller queue |
 |
|
Acolyte
Joined: 04 Apr 2013
Posts: 73
|
Hi ,
There are 10 messages in the timer controller queue with some specific start time given to them .
And is there any way to start them before the specified time. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Tue Nov 19, 2013 6:23 am Post subject: Re: Timer controller queue |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sai kumar adduri wrote: |
| is there any way to start them before the specified time. |
Why would you want to? The point of a timer node is to count down to a specific time.
If you want something to start on an event but no later than a given time, you need to combine them with something else in your design.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| sai kumar adduri |
| Posted: Tue Nov 19, 2013 6:31 am Post subject: |
|
|
Acolyte
Joined: 04 Apr 2013
Posts: 73
|
Reason:
I am using this to re initiate a web service call.So if the first retry message hit the service and gets processed then why do I want the other messages to be queuing there waiting for their turn , who knows the service may be down again. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Nov 19, 2013 6:43 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sai kumar adduri wrote: |
Reason:
I am using this to re initiate a web service call.So if the first retry message hit the service and gets processed then why do I want the other messages to be queuing there waiting for their turn , who knows the service may be down again. |
Or it may be back up.
So, to be clear in my mind, you have a flow which calls out to a web service and, when the web service is down you use a timer node to initiate a retry n seconds later. Due to the length of the outage you have x requests (10 in your example) waiting to retry. The first retry message hits timer expiry and fails again. At this point you want to abort all the queued retries, including those which have accumulated during the n seconds the first one was waiting? Do I have that right?
If so:
- what do you want to do if the first queued retry fails after n seconds, but the service is restored after n+1 seconds, i.e. in time for the 2nd queued retry to suceed?
- what do you want to do with the additional web service requests which are presumably still coming in and generating more retry requests?
- what is the issue with simply allowing these to fail a second time?
Better intformation, better advice
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| sai kumar adduri |
| Posted: Tue Nov 19, 2013 7:08 am Post subject: |
|
|
Acolyte
Joined: 04 Apr 2013
Posts: 73
|
First thing retry message will not fail .
and the second thing is that if the first retry message hits the service and gets a response which means the service is running .So why do we want the remaining message s to be in the queue, rather than sending them to hit the service. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Nov 19, 2013 7:30 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sai kumar adduri wrote: |
| First thing retry message will not fail . |
OK, I may have phrased that badly. I meant that the retry message will be processed successfully, but it hits the web service and again receives an error.
| sai kumar adduri wrote: |
| the second thing is that if the first retry message hits the service and gets a response which means the service is running .So why do we want the remaining message s to be in the queue, rather than sending them to hit the service. |
Ok, what you're saying is that if the first message retries and succeeds, you want the remaining queued messages to be retried immediately rather than waiting for their timeout to expire.
See my original comment - you'll need to combine the timer nodes with another element in your design to achieve this. You can't do this with just the timer nodes.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| sai kumar adduri |
| Posted: Tue Nov 19, 2013 7:35 am Post subject: |
|
|
Acolyte
Joined: 04 Apr 2013
Posts: 73
|
| Exactly !!! what could that other element would be any idea ? |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Nov 19, 2013 7:52 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sai kumar adduri wrote: |
| Exactly !!! what could that other element would be any idea ? |
Almost any mechanism by which you could store retry messages much as the timer node does, but allowing you to access it on demand. World's very much your oyster on that. The biggest issue is making sure that you don't get 2 retires; one timed, one "manual".
FWIW I've never really seen that the additional code, artifacts & overhead of building this sort of system has justified the cost benefit. I've always just let them retry automatically; if you need to retry for at least 60 seconds (for example) I express that as 6 tries 10 seconds apart so no retry is delayed more than 10 seconds.
This is in no way presented as the best method, the only method nor does it mean you should abandon your efforts in this area if you feel it has value in your scenario. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
