locale_refresh_cache called too often
| Project: | Location Views |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | agaric |
| Status: | needs review |
locale_refresh_cache seems to be called far more often than it ought to (when viewing not when setting a string), or else cause more database work than it should when it is called. I know it has been removed in Drupal 6 entirely.
My question, is there anything I can do in Drupal 5, right now, to deal with this?
Is there any way to track if having a t() function in a theme, or one t() function in a module in a place locale wishes it weren't called, is causing this.
In any case the whole caching process seems to cause an extreme amount of database activity-- on a test site with only custom English and Arabic enabled, and only one page, locale dumps more into the binary mysql logs with a few page views than a dozen other sites running for a day.
It does at least seem to stop once a page has been viewed by a given user. This is not the case on a site with a lot of languages installed, a lot of modules, a lot of content, and some t() calls in the theme.
Please, if anyone has any debugging advice, quick fix advice, news that Drupal 6 has been released with organic groups, views, and every other module we need ;-) ... PLEASE post here!
This is for the World Social Forum, WSF2008. Below are similar reports. Attached are notes and samples of what's being written to the database.
locale_refresh_cache bug
http://drupal.org/node/19444
fixed a year ago: $t = array();
Locale cache-handling cleanup
http://drupal.org/node/183056
explains the approach that took locale_refresh_cache out of Drupal 6
t() usage in global scope define()
http://drupal.org/node/186498
This blames subscriptions module for calling t() too early (in global scope, in a define)
| Attachment | Size |
|---|---|
| fresh_test_site.txt | 157.29 KB |
| two languages, clean install, visit a new page.txt | 657.27 KB |
#1
Simply using locale causes large jumps in database activity, but on a test installation with one page it does seem to stop.
With MySQL binary logging enabled, it will take down the web server by filling up the hard drive. This is insanity, it must have been recognized as such to remove it entirely in Drupal 6, is it fresh in anyone's mind what was done?
To try to debug this, what's the best way to call a backtrace when a particular function is called?
Lots of background:
http://AgaricDesign.com/note/mysql-binary-logs-death
#2
#3
#4
Haven't researched the problem but I assumed that the string should remain translatable. Your patch should be used to fix this if 'unknown' is fine, the patch on the duplicate should be used otherwise: http://drupal.org/node/287727