Image module and XMLsitemap conflict: Maximum Execution time exceeded errors while trying to access sitemap
| Project: | XML sitemap |
| Version: | 6.x-1.1 |
| Component: | Code |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | postponed (maintainer needs more info) |
Jump to:
Hello;
Ever since our sites' upgrade from Drupal 5 > 6 back in June, we have been having issues getting XMLsitemap to work on our site. At first when we enabled and configured the sitemap it builds correctly, however after a few runs of cron (after all the _node, _taxonomy, _user, and _user_role tables have been built), and when you try to access the sitemap file it hangs and becomes inaccessible. After some initial investigation it seemed to be something that occurs in conjunction with the Image module. It seems that the image module will piggy back on Cron runs to rebuild derivatives of images - and if there is a corrupt image (one with a bad path or such), it seems to hang up xmlsitemap.
Here is a sample of one of the errors which we receive.:
Fatal error: Maximum execution time of 30 seconds exceeded in /var/www/.../modules/node/node.module on line 425Here is a sample of some of the queries I was able to scrounge up that were running at the time:
SELECT t.* FROM term_node r INNER JOIN term_data t ON r.tid = t.tid INNER JOIN vocabulary v ON t.vid = v.vid WHERE r.vid = 5834 ORDER BY v.weight, t.weight, t.name
SELECT t.* FROM term_node r INNER JOIN term_data t ON r.tid = t.tid INNER JOIN vocabulary v ON t.vid = v.vid WHERE r.vid = 5246 ORDER BY v.weight, t.weight, t.name
SELECT t.* FROM term_node r INNER JOIN term_data t ON r.tid = t.tid INNER JOIN vocabulary v ON t.vid = v.vid WHERE r.vid = 12516 ORDER BY v.weight, t.weight, t.name
SELECT i.image_size, f.filepath FROM image i INNER JOIN files f ON i.fid = f.fid WHERE i.nid = 8768
SELECT i.image_size, f.filepath FROM image i INNER JOIN files f ON i.fid = f.fid WHERE i.nid = 1261
SELECT i.image_size, f.filepath FROM image i INNER JOIN files f ON i.fid = f.fid WHERE i.nid = 74
SELECT i.image_size, f.filepath FROM image i INNER JOIN files f ON i.fid = f.fid WHERE i.nid = 1103
SELECT i.image_size, f.filepath FROM image i INNER JOIN files f ON i.fid = f.fid WHERE i.nid = 2543
SELECT i.image_size, f.filepath FROM image i INNER JOIN files f ON i.fid = f.fid WHERE i.nid = 2143One of the really intesting things and not sure if it is by design is that when you first enable XMLsitemap and run cron to populate the databases, all the databases populate except for the main XMLsitemap database. THis one does not populate until you try to access sitemap.xml. Becuase of this even if you have valid data your sitemap will not load if there is a single piece of corrupted data (an image node that points to a bad url, etc...)
I am anticipating using the 2.x branch of XMLsitemap because it makes use of the batch api. I believe this should help solve the issue - however for those people out there who can't easily upgrade their installations of PHP to the latest version which the 2.x branch requires, having something that works well even with the case of some bad data would be benificial.
I'll provide more information as I continue to debug this issue.
Best,
Jared Scott
Senior Developer
HomeSavvi Inc.
#1
This sounds like it's a bug with image.module. Have you looked around in their issue queue to see if it's been reported or fixed.
Just curious, which version of PHP are you running? I'm trying to figure out if I can loosen that restriction up a little bit.
#2
Initial scan of the image module queue pops up with #226121: don't manipulate images on hook_load which was fixed on Sep 13th.
#3
Our production and dev servers are running PHP 5.1.2. We our currently using Ubuntu 6.06 LTS and have been looking at upgrading to 8.04 LTS because of incompatibility issues that are beginning to crop up with 5.1.x . I am running a version with PHP 5.2.6 on my localhost which is how I tested the 6.2.x branch of XMLsitemap.
Let me check that issue which you pointed out. We are currently running Image 6.x-1.0-beta3 because I thought that this was exactly that issue - however it is still cropping up.
One thing that I am still wondering about - why does the XMLsitemap main database populate when you try to access sitemap.xml? It seems to me that this would be a bad time to build that database, especially if your site has a high number of nodes.
Thanks for the quick responses
#4
And this is the reason for 6.x-2.x which is a work in progress but has been proven to work.
#5