Fatal error adding large articles - Corrupt Cache

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

Powered by eZ Publish™ CMS Open Source Web Content Management. Copyright © 1999-2014 eZ Systems AS (except where otherwise noted). All rights reserved.

eZ debug

Timing: Jan 31 2025 01:29:06
Script start
Timing: Jan 31 2025 01:29:06
Module start 'layout'
Timing: Jan 31 2025 01:29:06
Module start 'content'
Timing: Jan 31 2025 01:29:06
Module end 'content'
Timing: Jan 31 2025 01:29:06
Script end

Main resources:

Total runtime0.0230 sec
Peak memory usage4,096.0000 KB
Database Queries3

Timing points:

CheckpointStart (sec)Duration (sec)Memory at start (KB)Memory used (KB)
Script start 0.00000.0053 588.2578151.2266
Module start 'layout' 0.00530.0043 739.4844220.7188
Module start 'content' 0.00960.0120 960.20311,009.8047
Module end 'content' 0.02160.0014 1,970.007841.9922
Script end 0.0230  2,012.0000 

Time accumulators:

 Accumulator Duration (sec) Duration (%) Count Average (sec)
Ini load
Load cache0.002611.1075140.0002
Check MTime0.00104.4335140.0001
Mysql Total
Database connection0.00052.209510.0005
Mysqli_queries0.002711.711030.0009
Looping result0.00000.092310.0000
Template Total0.00104.410.0010
Template load0.00083.266010.0008
Template processing0.00031.109410.0003
Override
Cache load0.00052.265510.0005
General
dbfile0.00031.339680.0000
String conversion0.00000.042540.0000
Note: percentages do not add up to 100% because some accumulators overlap

Templates used to render the page:

UsageRequested templateTemplateTemplate loadedEditOverride
1print_pagelayout.tpl<No override>extension/community/design/community/templates/print_pagelayout.tplEdit templateOverride template
 Number of times templates used: 1
 Number of unique templates used: 1

Time used to render debug report: 0.0001 secs