So, we're experiencing a really weird issue with 2 umbraco sites we've built. First one is running on umbraco v 4.0.4.2, second one is running on umbraco v 4.7. Both of them are situated on our webserver, with many other websites, which is a 64 bit Windows Server 2008 R2 Standard server with 8GB RAM.
What happens is sometimes the client has to publish a page twice in order to make the changes visible on the website. When publishing once, the XML cache get's updated, but the changes are not visible on the website. It looks like the website uses the version 'current' - 1... Also programmatically created/published Documents are sometimes not visible until you publish them manually.
What I've done; - Copy the website to my local machine (with SQL DB running local); works fine - Copy the website to my local machine (with live SQL DB connection); works fine - Copy the website to the same server, running on another domain and app pool; same problem
Debugging problem; it's not happening all the time. Just tested and at the moment it's working fine...
So my questions are: - Has anyone experienced the same problem? - How should I debug this issue? - How can we solve this issue?
Same problem here. Works fine on my local install, but on the server most of the time pages have to be published twice.
Running 4.7 as well. I haven't yet tried taking out my eventhandlers tomake sure it's not messing something up. Come to think of it, I have your 301 package installed on only this site and this is the only site that is having problems. So you fix it! ;-)
Server setup is similar (Win 2008 non-R2, 32 bit).
I removed the InfoCaster.Umbraco._301UrlTracker.dll and that was not the cause of it, I could still reliably reproduce the error on almost each publish.
Also something I noticed; if the problem is happening, Document Sorter is also not working. I'm 100% sure that packaged isn't the problem, but it's another clue the problem lies in umbraco or .NET and I'd say umbraco for 95%...
I've narrowed it down to my custom DateFolders eventhandler, not sure where it breaks, but there's sorting involved as well which indeed.. doesn't seem to work very well.
Well I have some options why the behavior is different (or not):
- Behavior is the same; on the server it's not happening all the time. Maybe locally it isn't happening by coincidence - Behavior is different; on the server there's much more traffic (front-end and back-end). Both sites where this problem occurs have some pretty high visitor counts (vvvarnhemnijmegen.nl & apenheul.nl). Also these websites have the most activity in the back-end...
Ok this is probably completely unrelated, but are there any different language settings between your local install and the server? For example I got this bug on the server, but not local: http://umbraco.codeplex.com/workitem/30273.
Well, I seem to have found the cultprit in my site. Whenever library.RefreshContent() was called, it would not update the content correctly. This MAY be because I've just done a sort and the content is still refreshing in the background.
There's quite a bit of content in this site (2000+ news articles). So what might actually be happening is that I'm doing a sort (in code) and when immediately after that doing RefreshContent(), that might cancel the regeneration of the XML cache somehow. When I comment out the RefreshContent() line, everything seems to work just fine.
FYI, it may be possible that in your eventhandler, RefreshContent() is not always called, which is why it's hard to reproduce. In my case, my aftersave event always calls RefreshContent. So have a look at your eventhandlers and see what's going on.
I found out that the sorter isn't working at the times the publishing has to be done twice, right? So I thought; the sorter should use the umbraco Document events. I'm also using the Document events for clearing our custom cache, including Linq2Umbraco, which I've used pretty much in this project.
So I wrote code to add a log entry whenever the cache get's cleared, take a look:
Sometimes the event handler isn't invoked when a publish has been done. Look at log ID's: 145104, 145067, 145062, 145057, 145052, 145047, 145042, 145024, 145019, 145014 and 145009...
I've narrowed it down to Linq2Umbraco and the way we are caching it via a Singleton pattern. I'm storing the Linq2UmbracoDataContext in the HttpContext's Cache, so all users share the same instance.
When something get's published in the back-end, the Document.After_Publish event get's fired and the cache get's invalidated (custom code). But it looks like sometimes the real publish itself get's executed a fraction of time after the Linq2Umbraco cache get's rebuilt.
There's no way that I know off to check if the publish is 100% done, is there?
So, what I did was eliminate all of the eventhandlers by turning them all off (commenting out the code). Then I re-enabled them 1 by one until I could reproduce the issue. Then I looked in that code and removed stuff until the issue was gone.
I suspect you're running an eventhandler that does something some of the time, but not always, which is why this seems to randomly go wrong for you.
Posting at the same time haha.
I can't think of any other option then to do an async call in a seperate thread that invalidates the cache a bit later. But that feels hacky.
So I think I found the culprit when it comes to Apenheul's website: It's a problem with caching L2U application wide and the publishing mechanism in umbraco. What happens: 1. User publishes a page 2. BeforePublish get's fired 3. The publish itself get's executed 4. The AfterPublish get's fired 4a. The Linq2Umbraco cache get's cleared 5. The umbraco.library.RefreshContent(doc.id) get's called inside the umbraco publishing mechanism
So what happens is that RefreshContent get's called after the L2U cache get's removed and in some cases, when a visitor requests a page (and L2U will be rebuilt automatically because it doesn't exist in the cache), RefreshContent has not been finished yet and the old data is loaded (and cached) in L2U.
So what I did is, add a step before 4a. which executes umbraco.library.RefreshContent(doc.id). I think this fixes it, will confirm this after our client has tested it.
Changes only visible after publishing twice
So, we're experiencing a really weird issue with 2 umbraco sites we've built.
First one is running on umbraco v 4.0.4.2, second one is running on umbraco v 4.7.
Both of them are situated on our webserver, with many other websites, which is a 64 bit Windows Server 2008 R2 Standard server with 8GB RAM.
What happens is sometimes the client has to publish a page twice in order to make the changes visible on the website.
When publishing once, the XML cache get's updated, but the changes are not visible on the website. It looks like the website uses the version 'current' - 1...
Also programmatically created/published Documents are sometimes not visible until you publish them manually.
What I've done;
- Copy the website to my local machine (with SQL DB running local); works fine
- Copy the website to my local machine (with live SQL DB connection); works fine
- Copy the website to the same server, running on another domain and app pool; same problem
Debugging problem; it's not happening all the time. Just tested and at the moment it's working fine...
So my questions are:
- Has anyone experienced the same problem?
- How should I debug this issue?
- How can we solve this issue?
Same problem here. Works fine on my local install, but on the server most of the time pages have to be published twice.
Running 4.7 as well. I haven't yet tried taking out my eventhandlers tomake sure it's not messing something up. Come to think of it, I have your 301 package installed on only this site and this is the only site that is having problems. So you fix it! ;-)
Server setup is similar (Win 2008 non-R2, 32 bit).
Hmm, maybe I'll try some things today or tomorrow and post my findings here...
Problem is it's happening from time to time, so very hard to debug :-/ Worst part is it's not happening locally...
FYI, installed packages:
Well I'm afraid none of these packages are the cause of this problem, but it's got something to do with umbraco itself...
The xml cache get's updated, but it looks like the in-memory cache doesn't and I'm not familiar enough with the underlying system of umbraco.
Update: Luckily, I have all of my eventhandlers in a seperate DLL. After removing that one, publishing started working reliably again.
Now, to figure out which of the eventhandlers is messing up the publish...
Hmmm interesting...
Also something I noticed; if the problem is happening, Document Sorter is also not working. I'm 100% sure that packaged isn't the problem, but it's another clue the problem lies in umbraco or .NET and I'd say umbraco for 95%...
I've narrowed it down to my custom DateFolders eventhandler, not sure where it breaks, but there's sorting involved as well which indeed.. doesn't seem to work very well.
Also, why the heck would the behaviour be different on the server as opposed to the dev environment?
Well I have some options why the behavior is different (or not):
- Behavior is the same; on the server it's not happening all the time. Maybe locally it isn't happening by coincidence
- Behavior is different; on the server there's much more traffic (front-end and back-end). Both sites where this problem occurs have some pretty high visitor counts (vvvarnhemnijmegen.nl & apenheul.nl). Also these websites have the most activity in the back-end...
Ok this is probably completely unrelated, but are there any different language settings between your local install and the server? For example I got this bug on the server, but not local: http://umbraco.codeplex.com/workitem/30273.
Jeroen
Hmm I don't think it is related to the culture bug. At our webserver it's only happening with two websites (as far as we're aware of...)
Well, I seem to have found the cultprit in my site. Whenever library.RefreshContent() was called, it would not update the content correctly. This MAY be because I've just done a sort and the content is still refreshing in the background.
There's quite a bit of content in this site (2000+ news articles). So what might actually be happening is that I'm doing a sort (in code) and when immediately after that doing RefreshContent(), that might cancel the regeneration of the XML cache somehow. When I comment out the RefreshContent() line, everything seems to work just fine.
FYI, it may be possible that in your eventhandler, RefreshContent() is not always called, which is why it's hard to reproduce. In my case, my aftersave event always calls RefreshContent. So have a look at your eventhandlers and see what's going on.
Never mind, this is a wrong assumption!
There's something else going on with Apenheul:
I found out that the sorter isn't working at the times the publishing has to be done twice, right? So I thought; the sorter should use the umbraco Document events.
I'm also using the Document events for clearing our custom cache, including Linq2Umbraco, which I've used pretty much in this project.
So I wrote code to add a log entry whenever the cache get's cleared, take a look:
id userId NodeId Datestamp logHeader logComment 145114 0 1337 2011-07-07 16:39:22.247 Custom The custom cache entries are cleared - ApplicationBase 145109 2 2908 2011-07-07 16:39:12.610 Publish 145108 0 1337 2011-07-07 16:39:12.400 Custom The custom cache entries are cleared - ApplicationBase 145107 2 2908 2011-07-07 16:39:12.280 Publish 145104 2 2908 2011-07-07 16:39:09.777 Publish 145103 0 1337 2011-07-07 16:39:09.560 Custom The custom cache entries are cleared - ApplicationBase 145102 2 2908 2011-07-07 16:39:09.437 Publish 145097 0 1337 2011-07-07 16:38:19.690 Custom The custom cache entries are cleared - ApplicationBase 145084 0 1337 2011-07-07 16:36:30.593 Custom The custom cache entries are cleared - ApplicationBase 145078 0 1337 2011-07-07 16:36:20.900 Custom The custom cache entries are cleared - ApplicationBase 145073 2 2908 2011-07-07 16:36:11.587 Publish 145072 0 1337 2011-07-07 16:36:11.343 Custom The custom cache entries are cleared - ApplicationBase 145071 2 2908 2011-07-07 16:36:11.227 Publish 145067 2 2908 2011-07-07 16:35:02.960 Publish 145066 0 1337 2011-07-07 16:35:02.693 Custom The custom cache entries are cleared - ApplicationBase 145065 2 2908 2011-07-07 16:35:02.487 Publish 145062 2 2908 2011-07-07 16:33:48.820 Publish 145061 0 1337 2011-07-07 16:33:48.587 Custom The custom cache entries are cleared - ApplicationBase 145060 2 2908 2011-07-07 16:33:48.393 Publish 145057 2 2908 2011-07-07 16:33:29.760 Publish 145056 0 1337 2011-07-07 16:33:29.510 Custom The custom cache entries are cleared - ApplicationBase 145055 2 2908 2011-07-07 16:33:29.310 Publish 145052 2 2908 2011-07-07 16:33:10.690 Publish 145051 0 1337 2011-07-07 16:33:10.433 Custom The custom cache entries are cleared - ApplicationBase 145050 2 2908 2011-07-07 16:33:10.247 Publish 145047 2 2908 2011-07-07 16:32:33.027 Publish 145046 0 1337 2011-07-07 16:32:32.727 Custom The custom cache entries are cleared - ApplicationBase 145045 2 2908 2011-07-07 16:32:32.570 Publish 145042 2 2908 2011-07-07 16:31:51.720 Publish 145041 0 1337 2011-07-07 16:31:51.473 Custom The custom cache entries are cleared - ApplicationBase 145040 2 2908 2011-07-07 16:31:51.333 Publish 145034 0 1337 2011-07-07 16:31:28.473 Custom The custom cache entries are cleared - ApplicationBase 145029 2 2908 2011-07-07 16:29:44.003 Publish 145028 0 1337 2011-07-07 16:29:43.780 Custom The custom cache entries are cleared - ApplicationBase 145027 2 2908 2011-07-07 16:29:43.650 Publish 145024 2 2908 2011-07-07 16:29:36.913 Publish 145023 0 1337 2011-07-07 16:29:36.737 Custom The custom cache entries are cleared - ApplicationBase 145022 2 2908 2011-07-07 16:29:36.613 Publish 145019 2 2908 2011-07-07 16:28:49.720 Publish 145018 0 1337 2011-07-07 16:28:48.077 Custom The custom cache entries are cleared - ApplicationBase 145017 2 2908 2011-07-07 16:28:45.720 Publish 145014 2 2908 2011-07-07 16:27:26.090 Publish 145013 0 1337 2011-07-07 16:27:25.900 Custom The custom cache entries are cleared - ApplicationBase 145012 2 2908 2011-07-07 16:27:25.707 Publish 145009 2 2908 2011-07-07 16:26:28.077 Publish 145008 0 1337 2011-07-07 16:26:27.587 Custom The custom cache entries are cleared - ApplicationBase 145007 2 2908 2011-07-07 16:26:27.420 PublishSometimes the event handler isn't invoked when a publish has been done. Look at log ID's: 145104, 145067, 145062, 145057, 145052, 145047, 145042, 145024, 145019, 145014 and 145009...
So that's kind of weird isn't it?
I've narrowed it down to Linq2Umbraco and the way we are caching it via a Singleton pattern.
I'm storing the Linq2UmbracoDataContext in the HttpContext's Cache, so all users share the same instance.
When something get's published in the back-end, the Document.After_Publish event get's fired and the cache get's invalidated (custom code).
But it looks like sometimes the real publish itself get's executed a fraction of time after the Linq2Umbraco cache get's rebuilt.
There's no way that I know off to check if the publish is 100% done, is there?
So, what I did was eliminate all of the eventhandlers by turning them all off (commenting out the code). Then I re-enabled them 1 by one until I could reproduce the issue. Then I looked in that code and removed stuff until the issue was gone.
I suspect you're running an eventhandler that does something some of the time, but not always, which is why this seems to randomly go wrong for you.
Posting at the same time haha.
I can't think of any other option then to do an async call in a seperate thread that invalidates the cache a bit later. But that feels hacky.
Feels hacky indeed... ;-)
So I think I found the culprit when it comes to Apenheul's website:
It's a problem with caching L2U application wide and the publishing mechanism in umbraco. What happens:
1. User publishes a page
2. BeforePublish get's fired
3. The publish itself get's executed
4. The AfterPublish get's fired
4a. The Linq2Umbraco cache get's cleared
5. The umbraco.library.RefreshContent(doc.id) get's called inside the umbraco publishing mechanism
So what happens is that RefreshContent get's called after the L2U cache get's removed and in some cases, when a visitor requests a page (and L2U will be rebuilt automatically because it doesn't exist in the cache), RefreshContent has not been finished yet and the old data is loaded (and cached) in L2U.
So what I did is, add a step before 4a. which executes umbraco.library.RefreshContent(doc.id). I think this fixes it, will confirm this after our client has tested it.
So for the v4.0.4.2 version, the fix was to remove RefreshContent() in our Document eventhandlers (e.g. AfterPublish) like Sebastiaan suggested.
Thanks mate!
is working on a reply...