Apache OpenOffice (AOO) Bugzilla – Issue 57491
CVS contains files which are not deliverd by web (staticized pages update)
Last modified: 2006-01-12 08:58:05 UTC
The CVS consists files which are not delivered by web-access. I had checked out a version of de.openoffice.org/index.html which is about 10 hours old and is not shown on the web,
http://de.openoffice.org/index.html shows rev 1.312 while 1.313 has been committed to CVS.
The page http://de.openoffice.org/index.html shows rev 1.313. Please check now. Also, do let us know if you face this issue with any other page. Reducing the priority as the page now shows the current version. Please feel free to assign the issue back to Support or increase the priority if this issue still exists. Thanks, Karishma-Helpdesk
http://test.openoffice.org/ During the "low performance timeframes" committed changes to webpages are not visible after a reasonable timeframe. In most cases the daily re-staticization resolves the problem for specific pages. Nevertheless this frustrates work on webcontent.
I deeply apologise for the inconvenience that you are facing due to improper revision change seen in the page,I am working on this and would update you as soon as possible. Regards Karthik-Helpdesk
The page http://test.openoffice.org/ shows the revision 1.32 and the one in cvs also shows the same,reducing the priority as of now and will query engineers to work on this as soon as possible. Regards Karthik-Helpdesk
I verified from the site logs that the publishing of the CVS files are working properly. Are there any other example other than this de.openoffice.org/index.html file which did not get updated in time. BTW, this page is already staticized. The current delay in a HTML page to be re-cached is 15 minutes over and above the time it takes for any of the CVS-commited change to be staticized.
So I understand that it takes two steps 1) restaticization 5-10 minutes after commit 2) refresh of the squid cache 15 minutes delay. Is it correct that the squid cache will refresh if a) the requests contain Pragma: no-cache or b) the browser "reloads" the page via cache-control: max-age=0 If yes then it shoudl still take not more than 5-10 minutes to make the changes visible when reloaded.
Stefan, you are correct in how the publishing and cache steps actually work. There might be a corner case one can run into when commiting multiple files (that are staticized) at the same time, but this should be *very* rare if not a lot of people are changing content in the same directory area. The workaround would be to re-commit the file(s) with a minor change(if possible). That will trigger the publishing again. If this does not solve it, please let us know the page details and we will check in the server side for any errors/failures to update this.
Thanks for the explanation. We will follow the steps you recommended and open issues if we run in the problem again.
verified, closing