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
On Thu, Sep 27, 2012 at 4:05 AM, Joshua Marantz jmara...@google.com 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
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
On Thu, Sep 27, 2012 at 4:29 PM, Joshua Marantz jmara...@google.com 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
On Thu, Sep 27, 2012 at 10:58 AM, Ben Noordhuis i...@bnoordhuis.nl 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
On Thu, Sep 27, 2012 at 10:58 AM, Ben Noordhuis i...@bnoordhuis.nl wrote:
On Thu, Sep 27, 2012 at 4:29 PM, Joshua Marantz jmara...@google.com 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
On Thu, Sep 27, 2012 at 11:15 AM, Joshua Marantz jmara...@google.com wrote:
On Thu, Sep 27, 2012 at 10:58 AM, Ben Noordhuis i...@bnoordhuis.nl 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
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 traw...@gmail.com wrote:
On Thu, Sep
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
On Wed, Sep 26, 2012 at 5:38 PM, Joshua Marantz jmara...@google.com 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
+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
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
On Wed, Sep 26, 2012 at 7:31 PM, Joshua Marantz jmara...@google.com 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
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 traw...@gmail.com wrote:
On Wed, Sep 26, 2012
14 matches
Mail list logo