0

I have a Azure Webjob which hits a WebApi. The WebApi sends back an acknowledgement in 4 - 5mins. So, I have declared the TimeOut for the HttpClient to be at 10 mins.

Now, if the WebApi is returning the response in less than 4 mins, it works fine. But if the WebApi is returning the response for a request in 4 min 30 sec, the azure webjob is not getting this acknowledgement. Instead, the HttpClient on the WebJob is waiting for 10 mins, and then timing out. Is there some kind of a time out on the Webjob that I'm missing?

Viktor KurDz
  • 41
  • 10

2 Answers2

1

There is a 230 second timeout for requests that are not sending any data back. Please see the answer of @David Ebbo in following thread.

https://social.msdn.microsoft.com/Forums/en-US/17305ddc-07b2-436c-881b-286d1744c98f/503-errors-with-large-pdf-file?forum=windowsazurewebsitespreview

There is a 230 second (i.e. a little less than 4 mins) timeout for requests that are not sending any data back. After that, the client gets the 500 you saw, even though in reality the request is allowed to continue server side.

So the issue of not receiving response from Web API is related to the timeout limit of Azure Web App. I also test it on my side. Though I set executionTimeout as 10min in web.config.

<httpRuntime targetFramework="4.6" executionTimeout="600" />

If the time of sending response from service side need more than 230s. I will get a 500 error on my client side.

public IEnumerable<string> Get()
{
    Thread.Sleep(270000);
    return new string[] { "value1", "value2" };
}

I suggest you accept the suggestion of @Thomas. Writing your response to a queue from your Web API and get the response which you needed from the queue.

So, is there no method to bypass this timeout?

The 230 sec limit also could be proved in following article.

there is a general idle request timeout that will cause clients to get disconnected after 230 seconds.

https://github.com/projectkudu/kudu/wiki/Configurable-settings

I haven't found any ways to modify this timeout for Azure Web App. Please try the workarounds which I mentioned above.

Amor
  • 8,325
  • 2
  • 19
  • 21
  • So, is there no method to bypass this timeout? I just need to increase it to 300sec since the request is sometimes complete in less than 230 sec, but goes over only a few times. – Viktor KurDz Mar 31 '17 at 07:07
  • I modify my reply based on your comment. – Amor Mar 31 '17 at 10:29
  • Since there was no way to implement the time out, I ended up following the suggestion of exposing a new endpoint on the WebApi, which provides the status of the request made earlier. Thanks! :) – Viktor KurDz Mar 31 '17 at 12:31
  • What if I'm not the one responsible for the remote API? I'm querying an SAP API that takes longer than 4 minutes to bring data back. And they cannot improve their performance. And even the webjob is cancelling after 4 minutes. How should I handle that? – Rick Wolff Oct 06 '20 at 21:09
0

If you are executing a long running task or function in the context of BrokeredMessages, they have a timeout hard coded to 5 minutes.

Utilizing Task I place my long running function inside one and passing it to this function to run and "relock" the BrokeredMessage:

/// <summary>
/// Maximum time lockout for a BrokeredMessage is 5 minutes. This allows the
/// timer to relock every 4 minutes while waiting on Task parameter to complete.
/// </summary>
/// <param name="task"></param>
/// <param name="message"></param>
private void WaitAndRelockMessage( Task task, BrokeredMessage message )
{
    var myTimer = new Timer( new TimerCallback( RelockMessage ), message, 240000, 240000 );

    task.Wait();

    myTimer.Dispose();
}

private void RelockMessage( object message )
{
    try { ((BrokeredMessage)message).RenewLock(); }
    catch( OperationCanceledException ) { }
}

Sample Usage:

var task = Task.Run( async () => { await m_service.doWork(); } );

WaitAndRelockMessage(task, message);
HouseCat
  • 1,559
  • 20
  • 22
  • I'm already "relock"ing the Brokered Message. There seems to be some kind of a time out only for the requests, since the WebJob is continuing to function even beyond 10 - 15 mins now – Viktor KurDz Mar 31 '17 at 07:02