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.
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:
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.
Since my last answer two years ago, the answer is now: yes, we use retry policies for almost everything in Umbraco at the moment. There is, however, a caveat: if people still use the old SqlHelper in their own code or packages then they don't benefit from retry strategies.
That said, we run thousands of sites on Umbraco Cloud at the moment that all use a SqlAzure database and we've had no problems with SqlAzure.
Does Umbraco 7 use a Retry Policy for connections to Azure, by default?
Yes or no question really :)
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:
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:
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:
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.
Hi Artyom. Did you find an answer for your question? I have the same questions...
Can someone answer this? I'm sure this is going to be increasingly popular
Since my last answer two years ago, the answer is now: yes, we use retry policies for almost everything in Umbraco at the moment. There is, however, a caveat: if people still use the old SqlHelper in their own code or packages then they don't benefit from retry strategies.
That said, we run thousands of sites on Umbraco Cloud at the moment that all use a SqlAzure database and we've had no problems with SqlAzure.
is working on a reply...