3

I'm working on a webjob that checks a Webserver for some data. Sometimes the Webserver is busy and will come back with a try again in a few seconds.

Problem is that if I just ignore it and go through the function, it will delete the message from the queue and I will not be able to retry the call.

My current solution (which I don't like at all) is to through an exception which will increase the dequque number and put the message back on the queue. This however seems very brutal and requires the thread which the webjob is running on to restart.

Is there any other way of handling this?

hjavaher
  • 2,589
  • 3
  • 30
  • 52
  • 1
    You could try this: run your job asynchronously and check the server response for "try again in a few seconds". If it comes back with that response, then sleep for a few seconds and then try again. I'm not overly familiar with async operations, but it seems like you could implement something like that that would solve your exception problem and wouldn't use resources while you wait for the server. – EJay Jan 21 '15 at 16:12

1 Answers1

5

The webjobs SDK will retry queue triggered functions if they throw an exception. The number of retries is configured through the JobHostConfiguration.Queues.MaxDequeueCount property as described here.

If you don't want to rely on the SDK's retry policy, you can always handle the exception in your own code and retry. Just catch the exception or whatever happens when the server is busy and then retry the operation until it succeeds. However, this is exactly what the SDK does behind the scene and by doing this yourself, you don't get the automatic move to poison queue functionality.

Unless the function cannot be designed to be reentrant, I recommend letting the SDK do the retry job. If you still decide to handle it yourself, here is how the code could look like:

public static void WebJobFunction([QueueTrigger("temp")] string message)
{
    int retriesLeft= 5;

    while(true) 
    {
       try
       {
            --retriesLeft;
            DoServerOperation(message);
            break;

        }
        catch(TimeoutException)
        {
            if (retriesLeft == 0) 
            {
               throw;
            }
        }       
    }
}
Victor Hurdugaci
  • 28,177
  • 5
  • 87
  • 103
  • 1
    Hi Victor, Thank you for the help. I do like the way the SDK Handles the poison functionality. I'm simply wondering if there is a way to return a value and let the sdk know that the message should go back on the queue for retry without triggering an exception. Does that make sense? – hjavaher Nov 03 '14 at 17:26
  • 1
    It makes sense but, unfortunately, there is no way to do that – Victor Hurdugaci Nov 03 '14 at 18:04
  • 1
    @VictorHurdugaci Can you please clarify/expand on this statement: "Unless the function cannot be designed to be reentrant, I recommend letting the SDK do the retry job."? – Howiecamp Dec 31 '15 at 04:14