Pertaining to memcached

[Ryan Gilfether]

I can not reproduce this problem. I've looked at the code and tried 
doing multiple page loads retrieving and setting data into the Memcache 
and it works fine on the PHP client. As far as the socket timeout 
problem, unfortunatley PHP does not currently offer a way to specify a 
timeout in the socket_connect() function call. You do however have a 
global option in your php.ini file to change seconds it takes for a 
socket connection to timeout. The default is 60 seconds. Look for the 
variable default_socket_timeout in the 'Fopen wrappers' section of your 
php.ini file.

Keep in mind, PHP sockets are still considered "Experimental" so 
hopefully they will fix that in future releases.

Ryan

-- 
Ryan Gilfether
Software Engineer
http://www.gilfether.com

Brad Fitzpatrick wrote:
> Nobody's really used the PHP API yet.  The Perl one has seen all the
> battle-testing.  Also, we have two reports now that non-epoll is kinda
> flaky, but in both cases I think the binary was built wrong.
> 
> Which version of libevent did you use?
> 
> I've never seen a kernel not free memory on process termination.  Sure
> you're looking at the right number?
> 
> Were you swapping, btw?
> 
> 
> 
> On Thu, 24 Jul 2003, plix devil wrote:
> 
> 
>>    I recently installed memcached for the purpose of testing it with
>>the PHP API.  Upon starting the daemon things went well for the first
>>connection, but after which it failed to respond (disconnect_all() was
>>called before the script terminated).  I tried restarting the daemon and
>>it worked again, but only for the first page load / connection.  I was
>>wondering what the cause of this might be (running it in the foreground
>>in verbose mode and the PHP client in debug mode didn't produce anything
>>- I do believe, however, that the socket_connect() call was hanging [the
>>PHP API is poorly written in this regard as socket_connect() doesn't
>>timeout and hangs the script indefinitely])?  I do believe the problem
>>to be with memcached, though I'm not sure how (maybe it's not properly
>>terminating connections, but then again one dead connection wouldn't
>>fill the pool).
>>
>>    Another problem that popped up was that when I killed the daemon
>>manually (there was no documented way of doing it otherwise) it failed
>>to free the memory so now the server has all of it's physical memory
>>tied up in cache for a process that isn't running.  I'm not sure the
>>cause of this, but a quick glance at the memcached code didn't reveal
>>any signal-handling code to me (freeing the memory on process
>>termination is still the kernel's job, but it appears to have failed in
>>this respect - I'm running a RedHat 2.4.18 kernel on this particular
>>machine without epoll).
>>
>>    Any insight into this would be greatly appreciated.
>>
>>    .plix
>>
> 
> 
>