Now that we've established that the TTL passed into the server-create call
is for reaping idle connections and not individual operation timeouts, I
want to ask about timing out individual operations.
If memcached freezes, then it appears my calls to 'get' will block until
memcached wakes up. Is t
This helps a lot. I think 600 seconds seems like a fine idle-reap timeout.
I need to investigate why some lookups take a second or more. Maybe
there's a mutex contention on my end somewhere.
Thanks!
-Josh
On Thu, Sep 27, 2012 at 2:08 PM, Jeff Trawick wrote:
> On Thu, Sep 27, 2012 at 1:55 P
On Thu, Sep 27, 2012 at 1:55 PM, Joshua Marantz wrote:
> That one call-site is HTTP_24/src/modules/cache/mod_socache_memcache.c,
> right? That was where I stole my args from.
no, subversion
> As the TCP/IP layer is a lower level abstraction than bathe apr_memcache
> interface, I'm still not cle
That one call-site is HTTP_24/src/modules/cache/mod_socache_memcache.c,
right? That was where I stole my args from.
As the TCP/IP layer is a lower level abstraction than bathe apr_memcache
interface, I'm still not clear on exactly what that means. Does a value of
600 mean that a single multiget
On Thu, Sep 27, 2012 at 11:15 AM, Joshua Marantz wrote:
> On Thu, Sep 27, 2012 at 10:58 AM, Ben Noordhuis wrote:
>>
>> If dlsym() is called with the special handle NULL, it is interpreted as
>> a
>> reference to the executable or shared object from which the call is
>> being
>> made. Thus
On Thu, Sep 27, 2012 at 10:58 AM, Ben Noordhuis wrote:
> On Thu, Sep 27, 2012 at 4:29 PM, Joshua Marantz wrote:
>> Thanks Ben,
>>
>> That might be an interesting hack to try, although I wonder whether some of
>> our friends running mod_pagespeed on FreeBSD might run into trouble with
>> it. I di
On Thu, Sep 27, 2012 at 10:58 AM, Ben Noordhuis wrote:
> If dlsym() is called with the special handle NULL, it is interpreted as a
> reference to the executable or shared object from which the call is being
> made. Thus a shared object can reference its own symbols.
>
> And that's how it w
On Thu, Sep 27, 2012 at 4:29 PM, Joshua Marantz wrote:
> Thanks Ben,
>
> That might be an interesting hack to try, although I wonder whether some of
> our friends running mod_pagespeed on FreeBSD might run into trouble with
> it. I did confirm that my prefork build has APR built with
> APR_HAS_TH
Thanks Ben,
That might be an interesting hack to try, although I wonder whether some of
our friends running mod_pagespeed on FreeBSD might run into trouble with
it. I did confirm that my prefork build has APR built with
APR_HAS_THREADS, which for some reason I had earlier thought was not the
case
On Thu, Sep 27, 2012 at 4:05 AM, Joshua Marantz wrote:
> RE "failing the build of my module" -- the dominant usage is via
> precompiled binaries we supply. Is there an apr query for determining
> whether apr was compiled with threads I could do on startup?
I don't think there's an official way b
RE "failing the build of my module" -- the dominant usage is via
precompiled binaries we supply. Is there an apr query for determining
whether apr was compiled with threads I could do on startup?
-Josh
On Wed, Sep 26, 2012 at 7:40 PM, Jeff Trawick wrote:
> On Wed, Sep 26, 2012 at 7:31 PM, Jo
On Wed, Sep 26, 2012 at 7:31 PM, Joshua Marantz wrote:
> Looking at source, I see that Jeff's patch, and the 'ttl' parameter in
> general, is only referenced under '#if APR_HAS_THREADS'. When I
> load-tested and found the timeouts, I was testing under Apache 2.2 Prefork,
> and thus that patched c
Looking at source, I see that Jeff's patch, and the 'ttl' parameter in
general, is only referenced under '#if APR_HAS_THREADS'. When I
load-tested and found the timeouts, I was testing under Apache 2.2 Prefork,
and thus that patched code is not even compiled, IIUC.
However I would still like to k
+dev (sorry for the duplicate; my first attempt failed due to not being a
subscriber).
Keeping modules-dev on CC if that's appropriate.
Thanks, Jeff, I was wondering if there was a units issue there. I'm still
wondering if anyone can describe the meaning of that argument in more
detail. Is that
+dev
Keeping modules-dev on CC if that's appropriate.
Thanks, Jeff, I was wondering if there was a units issue there. I'm still
wondering if anyone can describe the meaning of that argument in more
detail. Is that related to my multiget APR_TIMEUP returns? The phrase "time
to live of client c
On Wed, Sep 26, 2012 at 5:38 PM, Joshua Marantz wrote:
> Hi,
>
> I've been having some success with the apr_memcache_* functions. In
> load-tests, however, I'm finding a lot of timeouts
> with apr_memcache_multgetp. Specifically, the status returned with the
> individual elements is APR_TIMEUP.
Hi,
I've been having some success with the apr_memcache_* functions. In
load-tests, however, I'm finding a lot of timeouts
with apr_memcache_multgetp. Specifically, the status returned with the
individual elements is APR_TIMEUP.
This leads me to wonder what the significance of the second to las
17 matches
Mail list logo
