[geeklog-devel] No articles on geeklog.net when not logged in?

[Tom]

Thanks for the input.  

 

It has been a while since I have poked around the reading/writing of the cache files. Even if 2 cache writes happen both should contain the proper contents and the write shouldn’t produce a blank file (or with a 1 in it as previously happened).  

 

If an error does happen anywhere during the process the cache file should not be created. I think this is where our main problem lies. There was a problem reading the story data from the database and then the empty cache file is created for the story. This means everyone else until that cache file expires gets to see the result of the error. If the cache file isn’t created then the next user page request should hopefully fix the missing cache page (since a missing or expired cache page is treated the same).

 

Hopefully I will have time to look into adding a bit more error handling to try and catch this situation this month.  I also want to update Geeklog.net with the latest code and upgrade the forum plugin as well. BTW I notice I had 4 more reports yesterday of Geeklog.net being down. I may install the ban plugin I have upgraded which uses the Stop Forum Spam IP list to block all IPs on the list from any access to the site..

 

Tom

 

 

From: geeklog-devel [mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Dan Stoner
Sent: September-01-15 8:43 PM
To: Geeklog Development
Subject: Re: [geeklog-devel] No articles on geeklog.net when not logged in?

 

Here is what I found... hope it helps someone.

 

 

1.

The PHP function filemtime() returns a unix timestamp that is precise to the second.

 

This is a rather large window of time for two requests to interact (two cache writes triggered within a second).

 

 

 

2. 

> Who's familiar enough with that code to add some debug statements?

 

 

I poked at template.class.php.  It already has some debug bits ready to be enabled:

 

 

 

 /**

  * Determines how much debugging output Template will produce.

  * This is a bitwise mask of available debug levels:

  * 0 = no debugging

  * 1 = debug variable assignments

  * 2 = debug calls to get variable

  * 4 = debug internals (outputs all function calls with parameters).

  * 8 = debug caching (incomplete)

  *

  * Note: setting $this->debug = true will enable debugging of variable

  * assignments only which is the same behaviour as versions up to release 7.2d.

  *

  * @var       int

  * @access    public

  */

  var $debug    = 0;

 

 

 

 

 

The "touch" command is used to create an empty file.  I suspect this is the command that is actually creating the empty file. This code is a possible area to investigate:

 

 

 

        if ($TEMPLATE_OPTIONS['cache_by_language']) {

            $extra_path = $_CONF['language'] . '/' . $extra_path;

            if (!is_dir($TEMPLATE_OPTIONS['path_cache'] . $_CONF['language'])) {

                @mkdir($TEMPLATE_OPTIONS['path_cache'] . $_CONF['language']);

                @touch($TEMPLATE_OPTIONS['path_cache'] . $_CONF['language'] . '/index.html');

            }

        }

 

 

 

 

And there are already some debug statements in there just waiting for debug to be set to level 8.

 

        if ($this->debug & 8) {

            printf("<check_cache> Look for %s<br>", $filename);

        }

 

 

 

The actual write of the cache file begins at Line 1685. There are no debug statements there. What does PHP do if the file write fails? I don't see any error trapping / exception handling in there.

 

        $f = @fopen($filename,'w');

        if ($f !== false ) {

            if ($TEMPLATE_OPTIONS['incl_phpself_header']) {

                fwrite($f,

"<?php if (!defined('VERSION')) {

    die ('This file can not be used on its own.');

} ?>\n");

            }

            fwrite($f, $tmplt);

            fclose($f);

 

 

 

 

3. After writing up everything above, I was thinking back to some experience with Wordpress caching in a previous life and some of the hiccups we ran into.

 

If PHP is using one of its caching systems such as Alternative PHP Cache (APC), and depending on the server configuration (FastCGI), you can get unexpected results trying to use functions such as filemtime since one PHP process may cache the previous stat result even though another PHP process has "changed something on the filesystem".

 

 

4. A server configuration difference in either PHP process mode (modphp vs. fastcgi vs. php-fpm), PHP cache layer, etc. could explain why Tom is not able to reproduce the issue.

 

Or, the actual traffic hitting geeklog.net is just particular or peculiar.

 

 

 

- Dan Stoner

 

 

 

 

On Tue, Sep 1, 2015 at 2:34 AM, Dirk Haun <dirk at haun-online.de> wrote:

Tom wrote:

> Yes clearing the articles fixes the problem (which I just did).  Not sure
> why but it only seems to happen on Geeklog.net one in a blue moon (the cache
> files exist but have no text).

We seem to have a few more blue moons these days. I noticed the problem again a few days ago and deleted the cache and now it has happened again.

Who's familiar enough with that code to add some debug statements?


Dirk


--
https://www.themobilepresenter.com/

_______________________________________________
geeklog-devel mailing list
geeklog-devel at lists.geeklog.net
https://pairlist8.pair.net/mailman/listinfo/geeklog-devel

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist8.pair.net/pipermail/geeklog-devel/attachments/20150902/129b2d3b/attachment.html>