The patch is approved, and the issue closed. Cheers, Gunnstein
On Fri, Aug 13, 2010 at 11:21 AM, Gunnstein Lye <[email protected]> wrote: > Thanks for the detailed description! I have uploaded a fix at: > http://issues.ez.no/17096 > > This is pending internal review. > > Gunnstein > > > > On Wed, Aug 11, 2010 at 9:51 PM, Peter Keung <[email protected]> wrote: >> 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 >> > > > > -- > Gunnstein Lye > Product Support Engineer > [email protected] | www.ez.no | eZ Systems > -- Gunnstein Lye Product Support Engineer [email protected] | www.ez.no | eZ Systems -- Sdk-public mailing list [email protected] http://lists.ez.no/mailman/listinfo/sdk-public
