[Issues] [apr_memcache 0000069]: Reconnect to memcached database is not being handled smoothly

[issues at outoforder.cc]

The following issue has been SUBMITTED. 
====================================================================== 
http://issues.outoforder.cc/view.php?id=69 
====================================================================== 
Reported By:                menulis
Assigned To:                
====================================================================== 
Project:                    apr_memcache
Issue ID:                   69
Category:                   Error Handling
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             01-15-2007 08:21 EST
Last Modified:              01-15-2007 08:21 EST
====================================================================== 
Summary:                    Reconnect to memcached database is not being handled
smoothly
Description: 
I'm using apr_memcached library from custom Apache HTTP 2.2.3 module. I was
trying to test apr_memcached behaviour when remote memcached daemon is
shutdown and then started again. Results are as follows:

1. Initial request to apr_memcache_getp() returns 20014 (Internal error).
2. Several subsequent requests to apr_memcache_getp() returnsreturn 32
(Broken pipe).

After playing with gdb and httpd -X I've figured out that during initial
request (after memcached restart) statement inside apr_memcache_getp()

rv = apr_socket_sendv(conn->sock, vec, 3, &written);

returns APR_SUCCESS, which I guess shouldn't happen (maybe this is due to
we call apr_socket_timeout_set?). 

After 10-30 seconds reconnect finally happens as it is expected to do in
apr_memcache_find_server_hash function (/* Try the the dead server, every
5 seconds */).

However, having initially apr_memcache_server_create routine called as

rv = apr_memcache_server_create("localhost", 1121, 0, 5, 10, 60,
&server);

ends up creating all 10 (hard maximum) sockets which shouldn't happen as
well (I suppose hard maximum should be hit only and only if there are a
lot of concurrent requests).
====================================================================== 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
01-15-07 08:21  menulis        New Issue                                    
======================================================================