Customizable timeout to a scheduled job through Azure Portal
Add the ability to customize the timeout interval through the Azure portal.
This feature is right now only available through API.
To be clear, do you mean the retry policy for an HTTP request (which includes the timespan between retries and the number of retry attempts to make)?
Swagata Bhattacharyya commented
I know this is a very old chain but is the timeout configurable now? We have changed the retry interval to 5 minutes but it is still showing the timeout error after one minute.
We also need the ability on some jobs to set the http timeout longer than the current 60 second default.
There are also some that we would like to have much shorter as long durations we want to see flagged as an error quickly
"What I want is to customize the number of seconds before a request is flagged as timedout (for larger jobs"
I 1000% second that, how come you did not think of this?... seems basic scenario.
or you did think of it and decided to not have it?... why not?
Martin Suchan commented
Another option might be ignoring timeouts as errors. I have a web service method that takes about 1 minute to complete and I don't like to see all scheduled requests as timeout errors.
Arjan Noordende commented
The HTTP Request timeout needs to be configurable because the scheduler has no capability to check the result of an asynchronous call and retry on fail.
An asynchronous scenario would be ideal, but it requires 2 endpoints:
The first to start the activity (202) and a second to 'poll' if the activity was succesful until either a success code (200) or an error code, upon an error code (4xx, 5xx), the scheduler should retry the first endpoint to retry the activity after a configurable retry period and for a configurable number of times.
If the first endpoint responds with an error code, indicating failture to start the activity, it should also follow the retry procedure.
Without the above, what is currently offered is not sufficient to consider an asynchronous scenario viable, therefore a good intermediate solution is to increase the HTTP request timout. Personally I believe 60 seconds is already a lot better than 30.
AdminKevin Lam (Admin, Microsoft Azure) commented
We do not expose the capability of changing the HTTP request timeout in the API. You may be getting that confused with the timespan between retries or perhaps it's just a terminology confusion. Exposing the configurability of the number of retries and retry interval in the portal is definitely in our plans.
If you really did mean HTTP request timeout then it would be helpful to know what timeout you would need. Today this is not configurable as it has a more direct affect on COGs. We typically recommend for requests that have a long processing time to make the HTTP processing asynchronous and respond immediately with a 202.
Peter Andersson commented
What I want is to customize the number of seconds before a request is flagged as timedout (for larger jobs), but also the number of retries.