PHP Daemon marks Memcache as failed every few days

[Nathan Schmidt]

Are you setting data which is 'around 1 Mb' when serialized? You  
might be going over the 'max bucket size' every now and then. I've  
seen that happen when using otherwise reasonable defaults in php --   
client libs essentially go dark for the remainder of their lives when  
they get a NOT_STORED or SERVER_ERROR message. It's bad for web  
clients but awful with a long-running command line program.

What is strlen(serialize($oGraph)) ?

-n

On May 22, 2007, at 2:01 AM, Iain Bapty wrote:

> Dear All,
>
> I've developed a PHP Daemon application which retrieves data from a  
> web service every 5 seconds and saves the data using Memcache. The  
> application has been in development for a week with the daemon  
> running solidly for nearly 7 days. Over those 7 days, the daemon  
> has terminated a few times due to a loss of connectivity to the  
> Memcache.
>
> Notice: Memcache::set(): marked server 'localhost:11211' as failed  
> in D:\AJAX3\daemon.php on line 44
>
> The following line is used to add data to the Memcache.
>
> $memcache->set('Graph', $oGraph, false, 10)
>
> Note that the 5-second loop does not reconnect to Memcache on each  
> iteration. An initial connection is made when the daemon is started  
> and this connection is reused for each loop. Would it be better to  
> reconnect to Memcache every 5 seconds?
>
> The Memcached is running as a Windows service and there isn't  
> anything in the Windows Event Viewer to suggest that the daemon has  
> terminated.
>
> The error handling in the daemon is currently being revised so it  
> will gracefully handle this situation and reconnect to the  
> Memcache. However, I am planning on relying on the Memcache so any  
> comments on how to debug this issue would be very much appreciated.
>
> I'm running:
>
> PHP 5.2.1
> Memcache extension taken from http://pecl4win.php.net/ext.php/ 
> php_memcache.dll
> Memcached 1.2.1 ( http://jehiah.cz/projects/memcached-win32/)
> Running on Windows XP
>
> Thanks,
> Iain