Published changes only visible after bumping web.config
I started this on Twitter, I should really have started it here and linked to it on Twitter.
I have a multi-site installation where changes are published but not becoming visible until the web.config is bumped which is not ideal to say the least.
Niels suggested "check permissions and if the app pool is running in WebGarden mode", permissions seem fine and the app pool is limited to a single process which should mean it is not in WebGarden mode AFAIK. This however did get me thinking...
Each site in the installation has it's own SSL Certificate which means each site is configured independantly in IIS so the certificates can be bound to the correct site. I found out the hard way that each of these sites MUST be running under the same application pool or you run into issues which is understandable (this is new ground for me). I have double checked the server config and all but one of the sites were running under the same app pool except one but that site is not currently active. I have moved it into the same application pool as the others and will see if this rectifies the situation, I will post back my results.
Whats puzzling about this is that looking in umbraco.config the new published content is there, it's just not being pulled through to the site which makes me think it is more of a caching issue?
Using distributedCall in the umbracoSettings.config file to ping each domain after each publish seems to be working...for now!
After ensuring that all sites are running under the same application pool, then restarting the application pool the issue seems to now be resolved. Well done me :) and thanks Neils for pointing me in the right direction, the app pool was not something I had considered.
I've now tried setting XmlCacheEnabled to false and the problem persists. If it was permissions the changes would not be written to the umbraco.config but they are they're just not being pulled through to the site. I'm convinced this must somehow be related to the multiple sites in IIS pointing to the same Umbraco install. Anything along those lines that you can think of?
Sorry mate, not very familiar with multiple sites pointing to the same IIS. But, yes, I can imagine that's a problem.. Are you using 4.1+? I see this in the web.config:
<!-- Set this to true to enable storing the xml cache locally to the IIS server even if the app files are stored centrally on a SAN/NAS Alex Norcliffe 2010 02 for 4.1 --> <add key="umbracoContentXMLUseLocalTemp" value="false" />
Even though that points to the umbraco.config, it might also make a difference to what will be loaded in IIS?
If not, you're going to have to go and have a look at the in memory cache storage source code.
The initial issues I had was running them under seperate app pools but that's understandable because it creates issues when more than one of the pools tries to write content to umbraco.config at the same time. All sites are now running under the same app pool which resolved that issue.
Message posted on Twitter to see if anyone else is running a similar config:
I've been having the same issue as well. I moved separated all my bindings from one IIS site and created a new IIS site for each domain. Had to do this because of SSL cert purposes. All use the same app pool (using v 4.0.4.2)
What I noticed was that the main IIS site that had all the bindings (mysite.com) would publish fine but when I try to publish a different site, e.g. mysite.de, it would not show up once published. Doing an app pool recycle (or web.config nudge) would make the change visible.
So I figured I would login to the backend for mysite.de and publish an item for this site and it seemed to work fine. It seems that you have to login to the backend of each site to make published changes. Seems weird and not sure if there is a work around to this? Or a setting, IIS or otherwise, so that you can publish any site from just one umbraco login.
You beat me to it! I just made the same discovery as I tried each domain after your earlier post on Twitter it's a strange one and I think probably more of a server config issue than an issue with Umbraco. It seems like perhaps each site is maintaining it's own in-memory copy of the XML file which I find strange as I would have thought the memory allocation would be related to the app pool rather than the site but this is a little out of my current depth of knowledge right now.
We did have this issue, but we overcame it by using distributedCall in the umbracoSettings.config file to ping each domain after each publish so that each AppPool would refresh it's cache, this meant we were able to keep each site in different application pools.
This issue whilst improved is still not without problems. The multi-site installs now update with distributedCall enabled however they also throw an exception on every publish due to the fact they are all trying to write to the same umbraco.config file at the same time.
System.IO.IOException: The process cannot access the file 'D:\inetpub\wwwroot\example.com\root\App_Data\umbraco.config' because it is being used by another process.
I admit I didn't read the entire thread, but I think it's reccomended (?) that each load balanced server maintains it's own umbraco.config file? That's how we do it anyway and don't have any problems on the many sites we host with 2 load balanced servers.
If you read further up the thread you will see this is not actually a true load balanced environment but a multi-site install but because of the need for each site to have it's own SSL Certificate it is configured to have different sites in IIS but each pointing to the same installation. I may need to investigate further about load balancing to see if I can find a way to overcome the issues we are currently experiencing with the current solution. This isn't something I have experience with so need to do some further reading I think.
Yes indeed, the sites which get the distributed call do trigger the error about umbraco.config being locked. However we experimented at the time of needing this requirement and we did not find that the error actually caused any problems as the umbraco.config for all sites does contain the correct data (unlike in a load balanced situation). So the distributed call caused the cache of each site to rebuild which was the most important factor.
I guess ideally you could develop a service which could be remotely called which would trigger a site re-cache to avoid the error being triggered.
Hi Sebastiaan, I'm fairly confident I already know what is locking the file, its the working process for the first site that kicked off the publish and then pinged the other domains to update. In a true load balanced environment it wouldn't be an issue because they wouldn't be writing to the same file.
Jeavon, I agree I don't appear to see any issues as a result of the error and the error is never displayed to users but I am using ELMAH and every time someone publishes on the site I get an error report x4. The site in question is growing rapidly and as such the activity on the site is causing a lot of exceptions. Whilst I could filter the error reports I would prefer to fix it at source, after all prevention is better than cure ;)
That is exactly correct, the url of the site to which the Umbraco is logged in locks the file first. The others get pinged and attempt to open it, if I remember correctly it might only be the first distributed call which triggers the error (we have 6 sites in our situation) as it conflicts with the Umbraco recache, but subsequent calls run in a sequential order meaning each has completed changing umbraco.config before the next one tries.
Published changes only visible after bumping web.config
I started this on Twitter, I should really have started it here and linked to it on Twitter.
I have a multi-site installation where changes are published but not becoming visible until the web.config is bumped which is not ideal to say the least.
Niels suggested "check permissions and if the app pool is running in WebGarden mode", permissions seem fine and the app pool is limited to a single process which should mean it is not in WebGarden mode AFAIK. This however did get me thinking...
Each site in the installation has it's own SSL Certificate which means each site is configured independantly in IIS so the certificates can be bound to the correct site. I found out the hard way that each of these sites MUST be running under the same application pool or you run into issues which is understandable (this is new ground for me). I have double checked the server config and all but one of the sites were running under the same app pool except one but that site is not currently active. I have moved it into the same application pool as the others and will see if this rectifies the situation, I will post back my results.
Thanks Niels for triggering this thought :)
Whats puzzling about this is that looking in umbraco.config the new published content is there, it's just not being pulled through to the site which makes me think it is more of a caching issue?
Shortly after marking this as the solution the problem reocurred but since I am unable to mark the solution that did work for me please follow this link, http://our.umbraco.org/forum/core/general/22030-Published-changes-only-visible-after-bumping-webconfig?p=1#comment83570
Using distributedCall in the umbracoSettings.config file to ping each domain after each publish seems to be working...for now!
After ensuring that all sites are running under the same application pool, then restarting the application pool the issue seems to now be resolved. Well done me :) and thanks Neils for pointing me in the right direction, the app pool was not something I had considered.
Thought it might be too good to be true, unfortunately this is still an issue and driving me insane and the client. Back to the drawing board on this!
Have you tried setting XmlCacheEnabled to false? It may be an issue with the umbraco.config file (either permissions or something whacky going on).
Unfortunately it's not possible to "unresolve" posts at the moment, but you can update the solution once you have a working one. :)
I've now tried setting XmlCacheEnabled to false and the problem persists. If it was permissions the changes would not be written to the umbraco.config but they are they're just not being pulled through to the site. I'm convinced this must somehow be related to the multiple sites in IIS pointing to the same Umbraco install. Anything along those lines that you can think of?
Sorry mate, not very familiar with multiple sites pointing to the same IIS. But, yes, I can imagine that's a problem.. Are you using 4.1+? I see this in the web.config:
Even though that points to the umbraco.config, it might also make a difference to what will be loaded in IIS?
If not, you're going to have to go and have a look at the in memory cache storage source code.
The initial issues I had was running them under seperate app pools but that's understandable because it creates issues when more than one of the pools tries to write content to umbraco.config at the same time. All sites are now running under the same app pool which resolved that issue.
Message posted on Twitter to see if anyone else is running a similar config:
http://twitter.com/#!/ProNotion/statuses/90760863094542336
I've been having the same issue as well. I moved separated all my bindings from one IIS site and created a new IIS site for each domain. Had to do this because of SSL cert purposes. All use the same app pool (using v 4.0.4.2)
What I noticed was that the main IIS site that had all the bindings (mysite.com) would publish fine but when I try to publish a different site, e.g. mysite.de, it would not show up once published. Doing an app pool recycle (or web.config nudge) would make the change visible.
So I figured I would login to the backend for mysite.de and publish an item for this site and it seemed to work fine. It seems that you have to login to the backend of each site to make published changes. Seems weird and not sure if there is a work around to this? Or a setting, IIS or otherwise, so that you can publish any site from just one umbraco login.
You beat me to it! I just made the same discovery as I tried each domain after your earlier post on Twitter it's a strange one and I think probably more of a server config issue than an issue with Umbraco. It seems like perhaps each site is maintaining it's own in-memory copy of the XML file which I find strange as I would have thought the memory allocation would be related to the app pool rather than the site but this is a little out of my current depth of knowledge right now.
Read this, sounds like AppDomains are the issue here. Not yet sure of a workaround but can at least advise client how to update.
http://odetocode.com/Articles/305.aspx
Hi Simon,
We did have this issue, but we overcame it by using distributedCall in the umbracoSettings.config file to ping each domain after each publish so that each AppPool would refresh it's cache, this meant we were able to keep each site in different application pools.
Hope that helps,
Jeavon
Thanks for the headsup on that I will try it and hopefully it is the solution I am after.
This issue whilst improved is still not without problems. The multi-site installs now update with distributedCall enabled however they also throw an exception on every publish due to the fact they are all trying to write to the same umbraco.config file at the same time.
Any ideas how to overcome this?
Hi Simon,
I admit I didn't read the entire thread, but I think it's reccomended (?) that each load balanced server maintains it's own umbraco.config file? That's how we do it anyway and don't have any problems on the many sites we host with 2 load balanced servers.
-Tom
Hi Tom,
If you read further up the thread you will see this is not actually a true load balanced environment but a multi-site install but because of the need for each site to have it's own SSL Certificate it is configured to have different sites in IIS but each pointing to the same installation. I may need to investigate further about load balancing to see if I can find a way to overcome the issues we are currently experiencing with the current solution. This isn't something I have experience with so need to do some further reading I think.
Thanks, Simon
Hi Simon,
Yes indeed, the sites which get the distributed call do trigger the error about umbraco.config being locked. However we experimented at the time of needing this requirement and we did not find that the error actually caused any problems as the umbraco.config for all sites does contain the correct data (unlike in a load balanced situation). So the distributed call caused the cache of each site to rebuild which was the most important factor.
I guess ideally you could develop a service which could be remotely called which would trigger a site re-cache to avoid the error being triggered.
Regards,
Jeavon
Not much help maybe, but do check out LockHunter to see what's locking the file.
Hi Sebastiaan, I'm fairly confident I already know what is locking the file, its the working process for the first site that kicked off the publish and then pinged the other domains to update. In a true load balanced environment it wouldn't be an issue because they wouldn't be writing to the same file.
Jeavon, I agree I don't appear to see any issues as a result of the error and the error is never displayed to users but I am using ELMAH and every time someone publishes on the site I get an error report x4. The site in question is growing rapidly and as such the activity on the site is causing a lot of exceptions. Whilst I could filter the error reports I would prefer to fix it at source, after all prevention is better than cure ;)
That is exactly correct, the url of the site to which the Umbraco is logged in locks the file first. The others get pinged and attempt to open it, if I remember correctly it might only be the first distributed call which triggers the error (we have 6 sites in our situation) as it conflicts with the Umbraco recache, but subsequent calls run in a sequential order meaning each has completed changing umbraco.config before the next one tries.
Yes, I can see you would get a lot of error emails! Yes, indeed a fix would be ideal!
is working on a reply...