Fatal error adding large articles - Corrupt Cache

Next topic

Author	Message
neil clark	Friday 24 November 2006 3:43:43 am I have recently attempted to add a long piece of text as an article to ez (3.8.4) and ez threw up a database error. After some testing I found that the error was due to there being too much text for ez's search engine to index. After disabling the search index I was able to add the article fine. But I soon realised that the cache had become corrupt from the original database error of the first long article. Pages are displayed randomly no matter what link you click. I have tried clearing the cache from the site and from the shell which has no effect.
neil clark	Thursday 30 November 2006 2:03:31 am Any advice on this problem? We currently have site that's pretty slow to use ( www.uwesu.org ) with the cache turned off :( But if we turn the cache on we have a completely random site. As mentioned already have tried clearly the cache via admin and shell but no effect.
Kristof Coomans	Monday 04 December 2006 8:36:17 am Hi Neil Which cache do you mean? Are you sure the user you cleared the caches with has the permission to remove the cache files? independent eZ Publish developer and service provider \| http://blog.coomanskristof.be \| http://ezpedia.org
neil clark	Monday 04 December 2006 10:00:57 am Hi Kristoff thanks to responding, our web server guy is going to reply here with further details. cheers Neil
Tony Wood	Monday 04 December 2006 10:11:06 am Hi Neil, One other route to go down if the caching issue is unsolvable; A plan B if you will. Try using a Table of contents type class and then split the article over several pages. We have used this concept when the information for a single topic is too much for a single page. I know this does not help you in your current problem, but I hope it will give you an option. Ton Tony Wood : twitter.com/tonywood Vision with Technology Experts in eZ Publish consulting & development Power to the Editor! Free eZ Training : http://www.VisionWT.com/training eZ Future Podcast : http://www.VisionWT.com/eZ-Future
neil clark	Tuesday 05 December 2006 1:30:10 am Hi Tony thanks for the suggestion. We also came up with a simple plan B to solve the long article problem which was creating a new class which was a copy of the article class but with search indexing turned off on the main body of the text. Which was fine for what we needed. cheers Neil
sly fx	Tuesday 05 December 2006 1:46:15 am Hi We have tried clearing the cache both from the site (which runs as the same user as the server itself) and also logged in as root from the shell - neither have worked. This whole situation arrose from adding a large article and the search module failing on it's indexing sql queries. This would suggest that some sql queries that happen after the search module has done its stuff were not run and have cause the way the cache is used to become corrupt. Would this make sense? What tables/fields in the database determine which cache page is loaded?
Tony Wood	Tuesday 05 December 2006 2:08:56 am One technique we used a while ago is to increase PHP time-out or speed up the server by putting more RAM, CPU or an accelerator in it. Generally now really long pages are a no no.. Thinking about it, do you have translations on these long articles or are they in just one language? If so, upgrading to 3.9 will help as "i believe" it now do not republish every language when you change a single object. Tony Wood : twitter.com/tonywood Vision with Technology Experts in eZ Publish consulting & development Power to the Editor! Free eZ Training : http://www.VisionWT.com/training eZ Future Podcast : http://www.VisionWT.com/eZ-Future
neil clark	Wednesday 06 December 2006 4:02:59 am Hi Tony yes we have increased the php timeout, but for this particular page it didn't work. I realise long pages are a no no but it's what the content owner wants. see: http://www.uwesu.org/ez/index.php/ez_site/services_sites/jobshop/vacancies Like I mentioned we just turned off the search indexing and this is fine for us. But it is the aftermath of this problem that we really need some pointers on. My colleague (sly fx) said "This whole situation arrose from adding a large article and the search module failing on it's indexing sql queries. This would suggest that some sql queries that happen after the search module has done its stuff were not run and have cause the way the cache is used to become corrupt. Would this make sense? What tables/fields in the database determine which cache page is loaded?" Myself, Sly and a few students are trying to build a great students' union website with EZ see www.uwesu.org Any help on this would be appreciated.
Tony Wood	Thursday 07 December 2006 11:44:05 am For the search issue, you could try rebuilding the search tables using the search rebuild command come php cli. Info in the docs. Tony Wood : twitter.com/tonywood Vision with Technology Experts in eZ Publish consulting & development Power to the Editor! Free eZ Training : http://www.VisionWT.com/training eZ Future Podcast : http://www.VisionWT.com/eZ-Future