Hendry wrote:
On Sun, May 9, 2010 at 1:45 AM, Earnie Boyd earnie@users.sourceforge.net wrote:
Your issue is the second occurrence on the lists I've seen where Views has been enabled and the cached page data is being served longer that it should be. The first was phrased as a question about how long the cache is maintained. In realty the Drupal page cache is short lived. I'm not familiar with the Views code to know why it makes a difference.
Lifetime of the cached page is 3 hours, and when the issue arise, that page was just being cached. And when we go that particular page as authenticated user, the page was properly rendered.
You mean, there could be possibility Views module causing the problem?
I have no way to know. I just made an observation that two incidents involving page cache where Views was being used.
Is there any method or logging that can be enabled, without adding heavy load on server performance, for future investigations if the case happened again? I've trouble to reproduce this problem, and I can't just say that the Views module is being the suspect. Last time, Apache error logs and watchdog did not print out any error related to the issue.
I would suggest that on the next occurrence that you dump your database and import it to a development machine. Then you can use the devel module to help debug the issue. You'll want to have the devel module already installed so that the page cache isn't emptied by default. Do not import the sessions table nor the system table, have them already setup and waiting. Mirror as much of production setup as you can including the web server URL by using the /etc/hosts of your development machine.