Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Storage] updating to 11.1.4; handling storage network timeouts #2486

Merged
merged 2 commits into from
May 4, 2020

Conversation

brettsam
Copy link
Member

@brettsam brettsam commented May 4, 2020

Storage 11.1.4 now cancels network timeouts after 100 seconds by default: Azure/azure-storage-net#985

Our TimeoutHandler workaround is likely not needed at all anymore, however, I wanted to leave it in just to make sure. So I changed this to:

  1. Increase the timeout of our TimeoutHandler from 2 minutes to 3 minutes.
  2. Check and log if we get a network timeout to make sure it's behaving as we expect (and also for the added data).

If things go well and we never see the TimeoutHandler fire anymore, we can remove it completely and simplify these calls in a future release.

}
catch (StorageException ex) when (ex.InnerException is OperationCanceledException && !cancellationToken.IsCancellationRequested) // network timeout
{
Logger.StorageTimeout(logger, operationName, clientRequestId, sw.ElapsedMilliseconds);
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Most of the other changes were to allow me to plumb a logger through to here so all of this was centralized.


public static async Task<T> ExecuteWithTimeout<T>(string operationName, string clientRequestId, IWebJobsExceptionHandler exceptionHandler, Func<Task<T>> operation)
public static async Task<T> ExecuteWithTimeout<T>(string operationName, string clientRequestId,
IWebJobsExceptionHandler exceptionHandler, ILogger logger, CancellationToken cancellationToken, Func<Task<T>> operation)
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is kind of clunky, but this cancellationToken isn't used to cancel anything. But in order to determine if it was a network timeout (for logging only), I need to know if someone canceled the operation directly. Since this is hopefully a short-lived API, I'm okay with it being odd for now and this whole class will go away in a future update.

@@ -147,9 +147,9 @@ private async Task RunAsync(CancellationToken cancellationToken)
TaskSeriesCommandResult result = await _command.ExecuteAsync(cancellationToken);
wait = result.Wait;
}
catch (Exception ex) when (ex.InnerException is TaskCanceledException)
catch (Exception ex) when (ex.InnerException is OperationCanceledException)
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Took me a while to realize that moving this to OperationCanceledException did everything I needed. The new behavior throws an OperationCanceledException wrapped in a StorageException if the network hangs for 100 seconds. Now, that exception will bubble up to here and the loop will start over, just as we'd want it to. (and it behaves the same as before as TaskCanceledException : OperationCanceledException).

@brettsam brettsam requested a review from paulbatum May 4, 2020 15:29
Copy link
Member

@paulbatum paulbatum left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like there are some host changes here. I assume you are OK with updating both at the same time. LGTM.

@brettsam
Copy link
Member Author

brettsam commented May 4, 2020

Thanks! Yeah those host changes are fine. That TaskSeriesTimer is source-shared across a couple projects so they'll all get that update internally (which is how I can ship this in the extension without needing a host deployment).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants