Hi, this is a very interesting find. I suggest the following fix for this eZ Bug. eZ should have some sort of Garbage Collection/Shutdownhandler(plugin able, extendable) for those processes. If the system shuts down on eZExecution:cleanExit(), it should clean up the mess.
Please report this to the tracker. Best regards, Björn Dieding ----------------------------------------------- Björn Dieding | Executive Director xrow GmbH Enterprise Content Management Am Lindener Berge 22 30449 Hannover Phone: +49 (511) 473915401 Mobile: +49 (151) 12169868 Skype: bjoerndieding Email: [email protected] Web: http://www.xrow.com Phone (general office): +49 (511) 473 91 54 00 MD: Björn Dieding, Sören Meyer TIN: DE257265797 HRB: Hannover 202464 ----------------------------------------------- Disclaimer: This electronic transmission is strictly confidential and intended solely for the addressee. If you are not the intended addressee, you must not disclose, copy or take any action in reliance of this transmission. If you have received this transmission in error it would be helpful if you could notify xrow GmbH as soon as possible. -----Ursprüngliche Nachricht----- Von: [email protected] [mailto:[email protected]] Im Auftrag von Peter Keung Gesendet: Mittwoch, 11. August 2010 21:51 An: [email protected] Betreff: [Sdk-public] Incomplete cache file generation on eZ DFS setups Hi SDK, We've experienced the same cache problem on two large eZ DFS cluster setups. The first request for a page loads successfully and quickly but subsequent requests take a long time to respond. Then another page will be quickly loaded, but subsequent requests again hang. This cycle only needs to repeat a few times until server performance is severely affected and a busy server will crash. How to reproduce the problem: - Make successive page requests to a node that the current user does not have the permission to view, resulting in an access denied (kernel 1) error; for example "/users" or - Implement a server-side redirect operator within a full view template. Analysis: The first page request starts cache generation. However, in both of the above scenarios, it appears that viewcache generation is not properly completed with a full view of a node. For example, with the server-side redirect operator, the request is redirected in the middle of viewcache generation. And the "access denied" page, although is standard eZ Publish functionality, doesn't seem to conform to what the eZ DFS cache generation process is expecting. Thus, subsequent page requests are waiting for a cache file to generate, but that cache file has already stopped being generated. If you inspect the ezdfsfile table, you will find an entry similar to: INSERT INTO `ezdfsfile` VALUES ('var/tao/cache/content/tao/5-9b676f6081843e14c8d5682a3647f38f.cache.generating', 'var/tao/cache/content/tao/5-9b676f6081843e14c8d5682a3647f38f.cache.generating', '588803514a4a26a99554e43762fa66cf', , , 0, 1281244184, 0, 0); Manually removing that entry solves the problem for one more page load, but of course, the same entry will return and repeat the hanging cycle all over again. Unsuccessful solutions: - Using {cache-ttl} blocks at the top of the full view template to "turn off" viewcache. This still happens within what I'm calling the "viewcache context" and thus the problem still occurs. - Using ViewCacheTweaks (site.ini), as this is only possible per node and not feasible to maintain when needed to be applied per section, per class, and similar. - Setting the NonExistantStaleCacheHandling values (file.ini) to "generate" instead of "wait" appears to have no effect. Even if it did help, it might affect site performance unintentionally if you only wanted this setting to apply to certain nodes. Is there a way to forcibly complete or end cache generation in an operator in those cases within the current eZ DFS setup? Otherwise this seems like a critical bug - but we would like to get an opinion on this before we proceed. Peter -- Sdk-public mailing list [email protected] http://lists.ez.no/mailman/listinfo/sdk-public -- Sdk-public mailing list [email protected] http://lists.ez.no/mailman/listinfo/sdk-public
