We have a reoccuring problem - sometimes, when publishing content, the umbraco.config cache file is only partially written, the size will be 1 - 3 k instead of the normal 40,000+ k. When this happens, the site is stuck in the "website is restarting" mode until I delete the umbraco.config file and touch the web.config to restart umbraco - then the cache is recreated successfully and all is well.
What could be the cause of this behavior, as it only happens SOME of the time? We are running version 4.0.3, I believe this issue has occured on more rare occasions in the past, but has become more frequent recently.
I have the same problem, this happens constantly when two editors are working on the site at the same time. App pool is seperate for this site, only one umbraco instance uses it..
For now I've set ContinouslyUpdateXmlDiskCache to False, which seems to help. But that's not a real solution as the cache is now always in memory and never on disk.
It is good to know this issue isn't specific to our unique environment. I've been a bit nervous to try that config setting, does it slow down the site performance?
I haven't seen a difference Tom, our umbraco.config used to be about 35 megs large, but the site spins up really fast after an app pool recycle.
Mind you, what used to be in the umbraco.config is now held in memory, so it should be exactly as fast as before (the umbraco.config file is only a fall-back in case the in-memory copy is not there).
So I was afraid that the start-up of the site with a clean app pool would be slow, doesn't seem to be bad though.
Umbraco.config not fully written on SOME publish attempts
We have a reoccuring problem - sometimes, when publishing content, the umbraco.config cache file is only partially written, the size will be 1 - 3 k instead of the normal 40,000+ k. When this happens, the site is stuck in the "website is restarting" mode until I delete the umbraco.config file and touch the web.config to restart umbraco - then the cache is recreated successfully and all is well.
What could be the cause of this behavior, as it only happens SOME of the time? We are running version 4.0.3, I believe this issue has occured on more rare occasions in the past, but has become more frequent recently.
Thanks,
Tom
Tom,
Is the website running in its own app pool?
Regards
Ismail
Our website uses a good number of .net controls to connect to our Member Management System (Aptify), which also uses this app pool.
I have the same problem, this happens constantly when two editors are working on the site at the same time. App pool is seperate for this site, only one umbraco instance uses it..
For now I've set ContinouslyUpdateXmlDiskCache to False, which seems to help. But that's not a real solution as the cache is now always in memory and never on disk.
It is good to know this issue isn't specific to our unique environment. I've been a bit nervous to try that config setting, does it slow down the site performance?
I haven't seen a difference Tom, our umbraco.config used to be about 35 megs large, but the site spins up really fast after an app pool recycle.
Mind you, what used to be in the umbraco.config is now held in memory, so it should be exactly as fast as before (the umbraco.config file is only a fall-back in case the in-memory copy is not there).
So I was afraid that the start-up of the site with a clean app pool would be slow, doesn't seem to be bad though.
Great. Thanks for the input, I will have to give it a try.
is working on a reply...