Running 4.0.4.2, users in the CMS are occasionally getting server timeout errors, with this in the event log:
Exception: System.IO.IOException
Message: The process cannot access the file 'C:\inetpub\wwwroot\callcredit.epiphanydev1.co.uk\data\umbraco.config' because it is being used by another process.
StackTrace: at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath) at System.IO.File.Delete(String path) at umbraco.content.ClearDiskCache() in d:\TeamCity\buildAgent\work\7380c184e9fcd3ea\umbraco\presentation\content.cs:line 656 at umbraco.content.SaveContentToDisk(XmlDocument xmlDoc) in d:\TeamCity\buildAgent\work\7380c184e9fcd3ea\umbraco\presentation\content.cs:line 857 at umbraco.content.<>c__DisplayClass10.<SaveContentToDiskAsync>b__f(Object ) in d:\TeamCity\buildAgent\work\7380c184e9fcd3ea\umbraco\presentation\content.cs:line 880 at System.Threading.ExecutionContext.runTryCode(Object userData) at System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state) at System.Threading._ThreadPoolWaitCallback.PerformWaitCallbackInternal(_ThreadPoolWaitCallback tpWaitCallBack) at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback(Object state)
Is this caused by many users editing the back end at once, or is this something else?
Are you using load balancing? If so it's reccomended to exclude umbraco.config from your file-replication, or it can cause a locking issue. Not sure if it's the same issue though
When ContinouslyUpdateXmlDiskCache is disabled the umbraco.config is not created (recycle your app pool and it will be deleted). The contents of umbraco.config will be available in memory only. So after an app pool recycle the startup of the site will be slow (especially on large sites).
But it will definitely solve the disk access problem.
File Locking on Umbraco.Config
Hi,
Running 4.0.4.2, users in the CMS are occasionally getting server timeout errors, with this in the event log:
Exception: System.IO.IOException
Message: The process cannot access the file 'C:\inetpub\wwwroot\callcredit.epiphanydev1.co.uk\data\umbraco.config' because it is being used by another process.
StackTrace: at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.File.Delete(String path)
at umbraco.content.ClearDiskCache() in d:\TeamCity\buildAgent\work\7380c184e9fcd3ea\umbraco\presentation\content.cs:line 656
at umbraco.content.SaveContentToDisk(XmlDocument xmlDoc) in d:\TeamCity\buildAgent\work\7380c184e9fcd3ea\umbraco\presentation\content.cs:line 857
at umbraco.content.<>c__DisplayClass10.<SaveContentToDiskAsync>b__f(Object ) in d:\TeamCity\buildAgent\work\7380c184e9fcd3ea\umbraco\presentation\content.cs:line 880
at System.Threading.ExecutionContext.runTryCode(Object userData)
at System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading._ThreadPoolWaitCallback.PerformWaitCallbackInternal(_ThreadPoolWaitCallback tpWaitCallBack)
at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback(Object state)
Is this caused by many users editing the back end at once, or is this something else?
Having the same problem and I'm very curious what the answer is...
Try setting "ContinouslyUpdateXmlDiskCache" in your umbracoSettings.config to false.
Are you using load balancing? If so it's reccomended to exclude umbraco.config from your file-replication, or it can cause a locking issue. Not sure if it's the same issue though
@Sebastiaan
But wouldn't that stop updating the XML cache? What's the behavior if one disables that setting?
Yup, I believe the umbraco.config will only get updated periodically, perhaps only after a recycle of the app pool. Haven't tried this myself though.
Hi,
I've seen the same behaviour in 4.5 although I'm not sure if it's the same issue.
Take a look at this report on codeplex and let me know if you think it's the same bug.
http://bit.ly/aP1s3P
So, as I understand it from Richard Soeteman:
When ContinouslyUpdateXmlDiskCache is disabled the umbraco.config is not created (recycle your app pool and it will be deleted). The contents of umbraco.config will be available in memory only. So after an app pool recycle the startup of the site will be slow (especially on large sites).
But it will definitely solve the disk access problem.
Its not a load balanced box, but I'll try chnaging the setting and see if that works.
is working on a reply...