No-one knows?

The answer is: yes and no. :-)

We still have quite a few legacy APIs left over from the v4 era which don't use a retry strategy, all of our new APIs (most backoffice calls are redirected to the new APIs, at least in the Content and Media section) DO use a retry strategy.

We have a support case with Microsoft that seems to be related to retry logic in Umbraco (for an Azure application), could you maybe give me this information:

Could you please give further details on how the retry logic is implemented? I presume the with Umbraco as well you can configure the retry strategy.

• How many retries are done?
• How long is the wait time in-between?
• For which error numbers is retry executed?

All of these should be included:
https://azure.microsoft.com/en-gb/documentation/articles/sql-database-develop-error-messages/#transient-faults-connection-loss-and-other-temporary-errors

Are there any detailed log files where it is visible how the retries come after another?

I just started looking at Umbraco for a upcoming project when I saw this post. If Umbraco doesn't utilize RetryPolicy for Azure Cloud deployments it is essentially a critical component that I would suggest be addressed immediately. The lack of this logic could cause timeouts in the application for end users. Any idea when everything will be ported over to the new API? What version of Azure SDK is currently being deployed with Umbraco?

Our client's project is hosted on Azure Saas (Virtual machines) and we periodically experience a timeout error. Umbraco 7.2.4 is used.

Here is top of the call stack:

System.Data.SqlClient.SqlException (0x80131904): Timeout expired.  The timeout period elapsed prior to completion of the operation or the server is not responding.  This failure occurred while attempting to connect to the routing destination. ---> System.ComponentModel.Win32Exception (0x80004005): The wait operation timed out
   at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)
   at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose)
   at System.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj, Boolean& dataReady)
   at System.Data.SqlClient.SqlDataReader.TryConsumeMetaData()
   at System.Data.SqlClient.SqlDataReader.get_MetaData()
   at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString)
   at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async, Int32 timeout, Task& task, Boolean asyncWrite, SqlDataReader ds)
   at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, TaskCompletionSource`1 completion, Int32 timeout, Task& task, Boolean asyncWrite)
   at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method)
   at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior, String method)
   at System.Data.SqlClient.SqlCommand.ExecuteDbDataReader(CommandBehavior behavior)
   at StackExchange.Profiling.Data.ProfiledDbCommand.ExecuteDbDataReader(CommandBehavior behavior) in c:\Code\github\SamSaffron\MiniProfiler\StackExchange.Profiling\Data\ProfiledDbCommand.cs:line 235
   at System.Data.Common.DbCommand.System.Data.IDbCommand.ExecuteReader()
   at Umbraco.Core.Persistence.Database.<Query>d__7`1.MoveNext()
   at System.Collections.Generic.List`1..ctor(IEnumerable`1 collection)
   at System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source)
   at Umbraco.Core.Persistence.Repositories.VersionableRepositoryBase`2.GetPropertyCollection(Sql docSql, IEnumerable`1 documentDefs)
   at Umbraco.Core.Persistence.Repositories.MediaRepository.ProcessQuery(Sql sql)
   at Umbraco.Core.Persistence.Repositories.RepositoryBase`2.GetByQuery(IQuery`1 query)
   at Umbraco.Core.Services.MediaService.GetRootMedia()

What could be the reason of this? Can a lot of content versions be the reason as we have setup an utility, which every hour performs an update of the content therefore a previous version of this content is created every hour.

Another question - I know that Umbraco has retry policy logic implemented in some way:

• RetryPolicy.cs
• RetryStrategy.cs

But I am not sure that it is applied in Azure cloud envoronment. Is there a way to make Umbraco use that logic? How can I know/be sure that it is used? Analyzing the sources I see that there is some logging, but live website logs doesnt contain any retry logic entries in case of timeout errors.

Can someone answer this? I'm sure this is going to be increasingly popular

is working on a reply...