Re: memcache.c internals question

From: Date: Tue, 24 Jul 2007 20:06:36 +0000
Subject: Re: memcache.c internals question
References: 1  Groups: php.pecl.dev 
Request: Send a blank email to pecl-dev+get-4818@lists.php.net to get a copy of this message
On 24.07.2007 23:58, Ravi Menon wrote:
Hi, I saw your names on the 'Authors' list for the memcache.c php-client extension. Please let me know if you would prefer to forward this message to some other mailing list. We use the following versions in our production system: PHP Version => 5.2.0-8 memcache: Revision => $Revision: 1.62 $ and Revision => $Revision: 1.80 $ on some boxes.
I'd recommend trying a newer version first.
In both revisions, we sometimes see memcache 'pconnect()' failures with 'Unkown error' - confirmed with errno code to be '0' (Success) with extra logging. Our memcached runs locally on the same box where apache+php runs, so these are not remote connections. I looked at the 'memcache.c' code on 1.80 (memcache-2.1.2.tgz download), and in the following sequence: _mmc_pserver_list_dtor() ---> mmc_server_free(): I see the following lines for persistent streams: if (mmc->persistent) {
        free(mmc->host);
        free(mmc);
        MEMCACHE_G(num_persistent)--;
    }
I am not very familiar with the php internals, so I am assuming this is the standard 'free()' call that frees the stream. I am assuming this 'dtor' may get called during garbage collection (we have spiky loads in our system). Does this make the mmc stored in the 'persistent_list' stale? i.e. a subsequent call to pconnect() will find the hash entry via mmc_find_persistent(), but now the le->ptr contains the free()'d mmc?
No, the persistent destructor is called only when necessary, i.e. on PHP shutdown, not on request shutdown (as it's done with regular connections). The situation you described is impossible.
Or is there some magic ref-counting going on? Either-way I am assuming that a stale mmc on a 'mmc_get_version()' will be detected and a new connection attempted. The memcached never goes down and a independent monitoring script on the same box confirms that it periodically responds to the 'stats' request on a persistent connection.
That doesn't mean it cannot fail during some operation.
So we think the problem is in the php-client implementation. Any insights on various reasons why the pconnect() could fails will be really helpful.
I'm afraid it's almost impossible to debug something that is not reproducible and appears only sometimes. So we'll need some more information to look into it, a reproduce case would be perfect. But please first update your PECL/memcache and memcached, the problem might have been fixed in the new versions. -- Wbr, Antony Dovgal

« previous php.pecl.dev (#4818) next »