apr_memcache_multgetp hangs forever after network hiccup

[Geoff Greer]

I had some problems at work with CGIs spinning. Attaching gdb gave me this:

(gdb) bt
#0  0x008e17a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2

(gdb) f 2

333      misc/apr_reslist.c: No such file or directory.
        in misc/apr_reslist.c
Current language:  auto; currently c
(gdb) p reslist->timeout
$1 = 0



Geoff

#1 0x00166a86 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/ libpthread.so.0 #2 0x081e1cd7 in apr_reslist_acquire (reslist=0x8619860, resource=0xb6b7ec60) at misc/apr_reslist.c:333 #3 0x081df7d0 in ms_find_conn (ms=Variable "ms" is not available.) at memcache/apr_memcache.c:273 #4 0x081e0b27 in apr_memcache_multgetp (mc=0x86057c0, temp_pool=0x88262f0, data_pool=0x88202d8, values=0x8820318) at memcache/apr_memcache.c:1276 #5 0x081e8b90 in dbCache::get_mult_cachable_internal (this=0x87c27f8, cachename=0x81ff227 "unreaditem", cacheversion=1, start=0, end=14, [EMAIL PROTECTED]) at dbcache/dbcache.C:277 #2 0x081e1cd7 in apr_reslist_acquire (reslist=0x8619860, resource=0xb6b7ec60) at misc/apr_reslist.c:333 The resource list timeout was set to 0, so some network trouble caused the CGI to sit there forever. Attached is a patch to fix the problem. The #defined timeout of 5 seconds is fine for what I need, but it would good to expose it (apr_memcache_timeout_set?) for users to customize.

memcached_hang_fix.patch
Description: Binary data