Whenever I am trying to add a property to a particular Document Type, I am met with a timeout error.
The Document Type I am updating has around 450 nodes, this doesn't seem like a lot. Lesser used Document Types are taking the changes just fine.
Some of the errors in the logs:
System.Data.SqlClient.SqlException (0x80131904): Lock request time out period exceeded.
System.Data.SqlClient.SqlException HResult=0x80131904 Message=Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
At first, I thought this was a uSync issue, however, a manual edit and publish causes the same problem.
I have done a ton of googling and this seems to be a common occurrence, no solution appears to work.
I've tried:
Different Connection Timeout to the connection string, and setting a higher Value
Sometimes this seems to make a difference although the publish will be stuck spinning forever with no error returned. I see lots of locking errors in the logs, and it's random if the change will take or not.
I can't help much I'm afraid, but I've had these same issues on an 8.18.8 site on Umbraco Cloud (also Azure under the hood), but have not yet seen them on a regular Azure site running Umbraco 12.
I don't have much evidence for this but I have a hunch that it is an Umbraco 8.x bug. If you can't resolve this, it may be worth reconsidering the "trying to avoid an Umbraco update". There are a lot of advantages to moving from .NET Framework to .NET 7.
Since you're on Azure already, you could reach out to whomever manages the Azure resources and see if they can give you data on the database utilization. If it's hitting its limit, that may be your problem. If it's not, it's more likely a bug. If you have a lot of custom code, though, it's likely to be a big effort.
While updating 400 document types at a time probably isn't a common use case, I don't think that should be expected to cause database connection timeout issues. If you meant 400 nodes from 1 doctype change, then that definitely shouldn't be expected to cause a performance issue if it's running as a one-time change.
Timeout and Locking Issues umbraco v8.6.1
Whenever I am trying to add a property to a particular Document Type, I am met with a timeout error.
The Document Type I am updating has around 450 nodes, this doesn't seem like a lot. Lesser used Document Types are taking the changes just fine.
Some of the errors in the logs:
System.Data.SqlClient.SqlException (0x80131904): Lock request time out period exceeded.System.Data.SqlClient.SqlException HResult=0x80131904 Message=Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.At first, I thought this was a uSync issue, however, a manual edit and publish causes the same problem.
I have done a ton of googling and this seems to be a common occurrence, no solution appears to work.
I've tried:
Connection Timeoutto the connection string, and setting a higher Value<add key="Umbraco.Core.MainDom.Lock" alue="SqlMainDomLock" /><add key="Umbraco.Core.SqlWriteLockTimeOut" value="2000" /><add key="Umbraco.Core.LocalTempStorage" value="EnvironmentTemp"/><add key="Umbraco.Examine.LuceneDirectoryFactory" value="Examine.LuceneEngine.Directories.SyncTempEnvDirectoryFactory, Examine" />The database is an Azure instance which I have very little control over (and knowledge for that matter) if that makes any difference.
I am using v8.6.1 and due to reasons (corporate shenanigans), I am trying to avoid an Umbraco update.
Any advice?
Thanks
I am fairly confident this will be due to whatever Azure plan the client is operating, apparently a query timeout of 30 seconds is standard.
Ignoring that for a moment, should updating 400 document types be taking this long?
I can't help much I'm afraid, but I've had these same issues on an 8.18.8 site on Umbraco Cloud (also Azure under the hood), but have not yet seen them on a regular Azure site running Umbraco 12.
I don't have much evidence for this but I have a hunch that it is an Umbraco 8.x bug. If you can't resolve this, it may be worth reconsidering the "trying to avoid an Umbraco update". There are a lot of advantages to moving from .NET Framework to .NET 7.
Since you're on Azure already, you could reach out to whomever manages the Azure resources and see if they can give you data on the database utilization. If it's hitting its limit, that may be your problem. If it's not, it's more likely a bug. If you have a lot of custom code, though, it's likely to be a big effort.
While updating 400 document types at a time probably isn't a common use case, I don't think that should be expected to cause database connection timeout issues. If you meant 400 nodes from 1 doctype change, then that definitely shouldn't be expected to cause a performance issue if it's running as a one-time change.
is working on a reply...