File locking on umbraco.config when ContinouslyUpdateXmlDiskCache is set to False
I have a load-balanced solution running Umbraco 4.7.2 and I am getting a confusing error message in the Umbraco Log which coincides with one of my servers returning a 200 error. The first error is as follows which is then followed by lots of messages stating that umbraco.config is in use by another process:
Error loading IApplication: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.TypeInitializationException: The type initializer for 'umbraco.content' threw an exception. ---> System.IO.IOException: The process cannot access the file 'C:\inetpub\wwwroot\TEMP-IIS01\umbraco.config' because it is being used by another process. at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath) at System.IO.File.Delete(String path) at umbraco.content.DeleteXmlCache() at umbraco.content.LoadContent() at umbraco.content.CheckXmlContentPopulation() --- End of inner exception stack trace --- at umbraco.content.add_AfterUpdateDocumentCache(DocumentCacheEventHandler value) at umbraco.LibraryCacheRefresher..ctor() --- End of inner exception stack trace --- at System.RuntimeTypeHandle.CreateInstance(RuntimeType type, Boolean publicOnly, Boolean noCheck, Boolean& canBeCached, RuntimeMethodHandleInternal& ctor, Boolean& bNeedSecurityCheck) at System.RuntimeType.CreateInstanceSlow(Boolean publicOnly, Boolean skipCheckThis, Boolean fillCache) at System.RuntimeType.CreateInstanceDefaultCtor(Boolean publicOnly, Boolean skipVisibilityChecks, Boolean skipCheckThis, Boolean fillCache) at System.Activator.CreateInstance(Type type, Boolean nonPublic) at umbraco.BusinessLogic.Application.RegisterIApplications()
I am slightly confused by this message as I have set ContinouslyUpdateXmlDiskCache to false so therefore umbraco.config does not even exist at this location and should not be being used at all.
If anyone can shed some light on this issue it would be most appreciated.
Still getting this issue on my site and it seems to occur when batch processes are being used such as using ZipUpload or Gecko Uploadify to import multiple media items.
Thanks for your reply Simon but even if this were the case, I have got ContinouslyUpdateXmlDiskCache set to false and therefore umbraco.config does not exist so it should not even be possible to lock it.
Without diving into the core I don't know for sure the inner workings of this but it's posisble that the ContinouslyUpdateXmlDiskCache configuration option may only apply to standard publish events. That said, I've looked at your original error again and strangely it is referring to the umbraco.config file being in what looks like the root of your site rather than the app_data folder which is a bit odd and possibly something to look at?
It would be great if someone who works on the core could comment or shed some light on this potential issue.
The location of umbraco.config is correct, it is because each server in the farm holds it locally rather than on the SAN where all other files are located.
File locking on umbraco.config when ContinouslyUpdateXmlDiskCache is set to False
I have a load-balanced solution running Umbraco 4.7.2 and I am getting a confusing error message in the Umbraco Log which coincides with one of my servers returning a 200 error. The first error is as follows which is then followed by lots of messages stating that umbraco.config is in use by another process:
Error loading IApplication: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.TypeInitializationException: The type initializer for 'umbraco.content' threw an exception. ---> System.IO.IOException: The process cannot access the file 'C:\inetpub\wwwroot\TEMP-IIS01\umbraco.config' because it is being used by another process. at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath) at System.IO.File.Delete(String path) at umbraco.content.DeleteXmlCache() at umbraco.content.LoadContent() at umbraco.content.CheckXmlContentPopulation() --- End of inner exception stack trace --- at umbraco.content.add_AfterUpdateDocumentCache(DocumentCacheEventHandler value) at umbraco.LibraryCacheRefresher..ctor() --- End of inner exception stack trace --- at System.RuntimeTypeHandle.CreateInstance(RuntimeType type, Boolean publicOnly, Boolean noCheck, Boolean& canBeCached, RuntimeMethodHandleInternal& ctor, Boolean& bNeedSecurityCheck) at System.RuntimeType.CreateInstanceSlow(Boolean publicOnly, Boolean skipCheckThis, Boolean fillCache) at System.RuntimeType.CreateInstanceDefaultCtor(Boolean publicOnly, Boolean skipVisibilityChecks, Boolean skipCheckThis, Boolean fillCache) at System.Activator.CreateInstance(Type type, Boolean nonPublic) at umbraco.BusinessLogic.Application.RegisterIApplications()I am slightly confused by this message as I have set ContinouslyUpdateXmlDiskCache to false so therefore umbraco.config does not even exist at this location and should not be being used at all.
If anyone can shed some light on this issue it would be most appreciated.
Thanks in advance
Paul
Still getting this issue on my site and it seems to occur when batch processes are being used such as using ZipUpload or Gecko Uploadify to import multiple media items.
Any help would be greatly appreciated.
Paul
Perhaps those packages are calling a method that attempts to force a refresh of the XML Cache?
Thanks for your reply Simon but even if this were the case, I have got ContinouslyUpdateXmlDiskCache set to false and therefore umbraco.config does not exist so it should not even be possible to lock it.
Paul
Without diving into the core I don't know for sure the inner workings of this but it's posisble that the ContinouslyUpdateXmlDiskCache configuration option may only apply to standard publish events. That said, I've looked at your original error again and strangely it is referring to the umbraco.config file being in what looks like the root of your site rather than the app_data folder which is a bit odd and possibly something to look at?
It would be great if someone who works on the core could comment or shed some light on this potential issue.
The location of umbraco.config is correct, it is because each server in the farm holds it locally rather than on the SAN where all other files are located.
BUMP!
I'll take a stab at it...
try also setting XmlContentCheckForDiskChanges in umbracoSettings.config to false
is working on a reply...