Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
Some minutes ago my inet connection was broken for some minutes... so i found out on my local box - if the remote server do not answer - the available update pages seems never times out the remote requests and after some time (1-2 minutes !?) the white screen of death is displayed.
i saw this on settings page.
Comment | File | Size | Author |
---|---|---|---|
#25 | 155450-25.update_status_cache.d5.patch | 17.35 KB | dww |
#23 | 155450_23_Backport_Cache_Update_Status.patch | 15.15 KB | Anonymous (not verified) |
#20 | 155450_20_Backport_Cache_Update_Status.patch | 16.11 KB | Anonymous (not verified) |
#18 | 155450_Backport_Cache_Update_Status.patch | 9.97 KB | Anonymous (not verified) |
Comments
Comment #1
hass CreditAttribution: hass commentedsame will happen if drupal,org is down or not answering, but my inet connection is fine... aside i ask myself why update_status is requesting for status everytime i click on the available update status page or setting page.
i thought this is a job that should be done by cron only.
Comment #2
dwwa) duplicate: http://drupal.org/node/146564
b) it's only trying to refresh since you don't have any data yet. once you have data, landing on the report or settings page just uses the cached info, and you only refresh on cron or if you do it manually.
Comment #3
dwwComment #4
NancyDruActually, Derek, I've notice this too and I definitely have data already.
Comment #5
dww@nancy: noticed what? timeouts, or refreshing the data, or what? please be specific. thanks.
Comment #6
NancyDruIt refreshes the data when I click on the update status link to see the report. It does not wait for me to click on "check manually." And it doesn't seem to matter how long it's been since the last check.
Comment #7
hass CreditAttribution: hass commentedchanged the topic now...
it looks "from outside" that every click inside update_status modules does a fetch on drupal, while it took very long to load. additional i saw this "white screen of death" what could confirm this. Do a manual check, change to settings page and it's fetched again... there seems nothing cached.
however another big question is - why the fetch of data is required on settings page... we are able to display a modules list table without items if nothing fetched already. In past there was a "check manually" on available updates page, now it fetches everytime i'm looking into the available updates or settings page and it looke like we have lost control when to fetch data.
Comment #8
hass CreditAttribution: hass commentedComment #9
NancyDruAhh, I now have a definite idea why the frequent refresh is happening. I've been watching my cache table, where you store the US data, and it appears that, on at least three of my sites, the cache is being cleared several times a day, so US is losing its data. Perhaps it needs to be moved to a dedicated cache, or better yet, a separate table.
Comment #10
dwwWhy is your cache getting cleared so often? That seems wrong. I don't really want to go through the trouble of a whole separate table or separate cache table, just for sites that can't keep their cache from getting cleared so often.
Comment #11
hass CreditAttribution: hass commentedFor me this looks like a false alarm... i placed a drupal_set_message line in the download part and learned it works correctly. however i don't know why the page loading is often very slow and why i got the "white screen of death", while my internet connection was broken.
Comment #12
NancyDruThe only culprit I've nailed down so far is a module that sets new content for a block once a day. But that will be every day.
Comment #13
dwwOne of the few tasks remainging from http://drupal.org/node/155483 (the issue for backporting all the goodness I added to the version of this module that landed in core) which isn't yet in the 5.x-2.* contrib version is that I setup a separate cache table just for the update status data, to protect ourselves from frequent cache clearing.
Comment #14
NancyDruI just had the need to browse the taxonomy module and it has a "cache_clear_all" on any update to a site's taxonomy. So, doesn't that mean ever taxo change is wiping out US's data?
Comment #15
dwwEeeek. Sucks to have a site with free tagging enabled, I guess. ;)
I'm too busy right now to do this myself, but I already basically wrote the code -- just compare with update.module in D6 core. So, if someone with php skills wanted to really help, they could work on this patch themselves. If not, I'll hopefully get to this some day, just not soon.
Thanks,
-Derek
Comment #16
dwwBased on #220592: Core cache API breaks update.module: fetches data way too often, kills site performance, etc (now in core) this is a critical task. I think it's worth a 5.x-2.4 release for this.
Comment #17
NancyDruSee #454410: Base table or view not found
Comment #18
Anonymous (not verified) CreditAttribution: Anonymous commentedI'm hoping that the SQL to generate this table is the same with pgsql. If so, then this patch should be fine.
Comment #19
dwwSuper cool, thanks!
I just got home from a very long day, and don't have time to carefully review/test in detail, but a quick skim showed a few things:
A) To prevent possible conflicts with people upgrading to core, and to be internally consistent with the D5 contrib version, we should call the table {cache_update_status}.
B) update_status_project_cache() needs to stay. The corresponding function in D6 and D7 core is called update_project_cache(). That serves a different role than _update_cache_get() (although it certainly calls _update_cache_get()...).
C) Sadly, no, pgsql and mysql table creation takes slightly different syntax in a few places. :( Here's what system.install does in the pgsql case for the core {cache} table:
that should be our model for this.
D) There needs to be a hook_install() to add the table when you first install, not just an update function when you upgrade.
E) Since this is a totally custom table and API, we might as well not even bother with the "headers" column.
F) D5 doesn't have the "serialized" column in cache tables at all, and in our case, everything we're caching is an array that needs to be serialized anyway, so we can both leave off that column and in our private API just automatically serialize/unserialize everything.
G) There's PHPDoc that references "_update_cache_clear()" even though that's really "_update_status_cache_clear()', etc.
H) Minor: there's some PHPDoc goodness that went into the final patch over at #220592: Core cache API breaks update.module: fetches data way too often, kills site performance, etc that'd be nice to backport while we're at it...
Comment #20
Anonymous (not verified) CreditAttribution: Anonymous commentedMan, I thought copy-paste was smarter than that. I don't know how it could have made such mistakes. ;)
Comment #21
Anonymous (not verified) CreditAttribution: Anonymous commentedForgot to change the status with my previous post.
Comment #22
dwwSweet, looks a lot better! A few remaining things:
I) In hook_uninstall():
+ db_query("DROP TABLE {cache_update}");
-- wrong table name.J) In the D6 patch, cid 'update_info' was renamed to 'update_status_available_releases'. In this patch, there's still a mix of both 'update_status_info' and 'update_status_available_releases'. Death to 'update_status_info'.
K) update.php doesn't do the whole MAINTENANCE_MODE == 'update' thing in D5. hook_flush_caches() was new in D6, too. :( We might just have to punt on that stuff and ignore update.php here. Not sure there's any good way to hook into update.php in D5 and clear our caches when it runs...
L) References to "Update module" should be "Update status" or "Update status module".
Almost there... ;)
Comment #23
Anonymous (not verified) CreditAttribution: Anonymous commentedI,J,K and L should be fixed now. (Next time I'll be more careful, lest you make it to Z.) ;)
Comment #24
Anonymous (not verified) CreditAttribution: Anonymous commentedI have this horrible habit of forgetting to change the status when appropriate.
Comment #25
dwwSorry, got swamped by "real life". :( This was mostly ready, but there were a few more problems:
M) The cache ids used throughout did not match the comments, etc. Now, everything consistently uses these: update_status_available_releases, update_status_project_data, update_status_project_projects.
N) Many of the update PHPDoc comments weren't wrapped to 80 chars.
O) The DB update number was out of sequence. The next available update number is 5203 -- patch #23 was using 5205 for no apparent reason. Also, cleaned up the PHPDoc comment for this update.
P) Added a CHANGELOG entry for this.
I'd love to get someone to test this on pgsql. Then I'll commit. Thanks for all your help, Joshua!
Comment #26
Damien Tournoud CreditAttribution: Damien Tournoud commentedTested this patch on PostgreSQL 8.3:
- installed a clean Drupal 5.18, installed Update status (5.x-2.x-dev), fetched status information, applied the patch, launch update.php, refetch status information ==> worked flawlessly
- installed a clean Drupal 5.18, installed Update status (5.x-2.x-dev) with this patch applied, fetched status information ==> worked flawlessly
Let's get this in, and save drupal.org infrastructure.
Comment #27
dwwCommitted to DRUPAL-5--2. Thanks!
p.s. See #478928: Release update_status 5.x-2.4 for the todo list before we can actually release this code officially...
Comment #29
mcurry CreditAttribution: mcurry commentedsubscribe