| View previous topic :: View next topic |
| Author |
Message |
Insomniac
Smarty Rookie
Joined: 07 Apr 2012
Posts: 6
|
 Posted: Thu Apr 12, 2012 6:57 am Post subject: Minor bug (throws a warning) |
 |
|
Warning: filemtime(): stat failed for .smarty/cache/a6b12cc91ba8c72704fee5c540533d952874ff4b.directory.tpl.php in /usr/local/lib/php/Smarty/sysplugins/smarty_internal_cacheresource_file.php on line 103
| Code: | Code:
/usr/local/lib/php/Smarty/sysplugins/smarty_internal_cacheresource_file.php:103
100. public function writeCachedContent(Smarty_Internal_Template $_template, $content)
101. {
102. if (Smarty_Internal_Write_File::writeFile($_template->cached->filepath, $content, $_template->smarty) === true) {
103. $_template->cached->timestamp = filemtime($_template->cached->filepath);
104. $_template->cached->exists = !!$_template->cached->timestamp;
105. return true;
106. }
107. return false;
108. } |
This is on a (very) high traffic site, so it's entirely possible it's hitting a race condition between requests, especially since I only find this warning once every couple of days or so.
Suppressing the warning @ would be suitable at a general glance, though perhaps there is more to it. |
|
| Back to top |
|
mohrt
Administrator
Joined: 16 Apr 2003
Posts: 7368
Location: Lincoln Nebraska, USA
|
|
| Back to top |
|
rodneyrehm
Administrator
Joined: 30 Mar 2007
Posts: 674
Location: Germany, border to Switzerland
|
| Posted: Thu Apr 12, 2012 3:46 pm Post subject: |
|
|
$cache_locking (currently) only applies to generating the cache. clearing a cache is disregarding that option.
My guess at what's happening here is
| Code: | [process 1] writeFile()
[process 2] clearCache()
[process 1] filemtime() |
The question is how clearCache() should hook into $cache_locking. Should the clear() wait for the writes() to finish? should the write() be aborted if a clear() interferes?
It's getting worse, as caches are hierarchical:
| Code: | Consider writeFile($template = 'foo.tpl', $cache_id = 'a|b|c')
and clearCache($template = 'foo.tpl', $cache_id = 'a|b') |
[file, database, memcache]-CacheResources implement hierarchy differently. With the filesystem, clearing a certain cache_id-group could mean simply removing a directory. With a database it could be a cache_id LIKE "a|b%" query. With KeyValueStores (memcache, APC, …) we don't really kill a child of given cache_id-group, but mark that group as invalid. We do that, because we have no way of identifying all the cache_ids in a group, as we cannot perform "range queries" on simple get/set APIs.
In short: we can only identify what we know. Since we can't in the clear process, we have to do it in the write process. This essentially means acquiring locks for every level of the cache_id-hierarchy. Which in turn would lead to throttling parallel write operations for ['a|b|1', 'a|b|2', 'a|b|3'].
_________________
Twitter |
|
| Back to top |
|
U.Tews
Administrator
Joined: 22 Nov 2006
Posts: 5068
Location: Hamburg / Germany
|
| Posted: Thu Apr 12, 2012 4:17 pm Post subject: |
|
|
It would be very interesting to get some feedback if you still see this warning if you set $smarty->cache_locking = true;
It does create some little overhead when cache files are refreshed, but should prevent race conditions and the waste of CPU time due to possible current updates of the same cache file on heavily loaded systems.
As Rodney mentioned there is still a chance of conficts on explict clearCache calls as these might not address a single template but any level of structured cache_id.
I'm currently not sure if @ error supression is sufficient solution for this problem. It needs some further investigation. |
|
| Back to top |
|
U.Tews
Administrator
Joined: 22 Nov 2006
Posts: 5068
Location: Hamburg / Germany
|
| Posted: Thu Apr 12, 2012 4:57 pm Post subject: |
|
|
I was able to create a test case for this problem.
The fix is now in the SVN trunk and will later be included in version 3.1.9 |
|
| Back to top |
|
Insomniac
Smarty Rookie
Joined: 07 Apr 2012
Posts: 6
|
| Posted: Thu Apr 12, 2012 7:46 pm Post subject: |
|
|
Awesome response times guys!
| U.Tews wrote: | | It would be very interesting to get some feedback if you still see this warning if you set $smarty->cache_locking = true; |
Would you still like me to give it a shot?
| U.Tews wrote: | I was able to create a test case for this problem.
The fix is now in the SVN trunk and will later be included in version 3.1.9 |
Excellent! |
|
| Back to top |
|
U.Tews
Administrator
Joined: 22 Nov 2006
Posts: 5068
Location: Hamburg / Germany
|
| Posted: Thu Apr 12, 2012 8:35 pm Post subject: |
|
|
Indeed there was a race condition when current cache updates for the same page could end up in the unexpected warning in some rare conditions. This hole is now closed by the patch.
But still concurrent cache updates can occur.
Depending on the required time to generate the new page (long lasting DB access etc.) it can eat up CPU time and worst case end in dead lock situations on very heay loaded systems. This was the main reasion for the new cache locking option.
So my recomendation for heavily loaded systems is to enable the cache locking option, accepting some little additional overhead on each cache refresh, but avoide the chance that current updates may end up in long response time.
A test with this option because your original problem of the warning is not necessary. |
|
| Back to top |
|
|
