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/foo/cache/content/foo/5-
9b676f6081843e14c8d5682a3647f38f.cache.generating',
'var/foo/cache/content/foo/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.