httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Frederic <>
Subject Re: 3.0 - Proposed Goals
Date Thu, 15 Feb 2007 08:59:47 GMT

> - Provide a generic inter-process data-sharing framework.  Currently
>   mod_ssl, mod_auth_digest, mod_ldap, and the scoreboard all use
>   more-or-less independent implementations of shared memory data stores.
>   As someone who maintains a module with yet another such data store,
>   I think a standard interface for such things (beyond apr_rmm) might be
>   useful.  Perhaps something key/value based; maybe aligned with memcached
>   somehow?  See my final musings below.
> - Provide a generic scoreboard interface for use by modules.  The
>   current scoreboard is effectively sized at initial startup to
>   max MPM processes * max MPM threads.  That wastes space, but also
>   provides no way for modules to register their own private threads.
>   As someone who maintains a module with such threads, I'd love to
>   see them in mod_status.  I'd also like to see the non-worker threads
>   from an MPM like worker in there too (i.e., listener, start, main);
>   I have a collection of incomplete patches to do this hanging around.
>    Admittedly, this may be a hard problem: how do you size the scoreboard's
> block of shared memory if modules can be added at restarts, and might
> suddenly require extra scoreboard space for their threads?  I have no good
> solution.  (Should the scoreboard use the above-mentioned generic
> data-sharing framework, or not?  Perhaps shared memory isn't even the
> right tool?)

You need different kinds of "shared" memory:
- stuff with one writer and several readers.
- stuff with several writes and several readers.
httpd-proxy-scoreboard in fact only solved the first one and only
provide memory organised in slotmem (records).
The idea to have a provider of "shared" memory and use it for the
scoreboard is of course a need for the next version and there should be
a way to access to httpd scoreboard from in external process (for
example a java process for JMX access). Once the configuration is
readable and dynamic it could be forwarded to the next node of an
"httpd" running in a cluster. 

If you have something something like the workers of mod_proxy it must
possible to add a new worker (a new node of cluster front-end by httpd)
without the need of restarting httpd. A not easy problem is to remove a

>    If we're generally moving to an increasingly asynchronous, threaded
> design then I think such a scoreboard might also serve as a valuable
> sanity check during development ("What the heck is that thread doing?")

One need thing is to be able from a module to ask for a "timeout": some
thing like a dummy request that happens after a timeout if no requests
are coming. (To query a back-end server for example).

>    An API which allowed threads to register their possible states might
> be valuable; this would allow modules/providers/MPMs to define what
> states were meaningful to them, rather than trying to define them
> all in scoreboard.h.
>    I confess I haven't followed the progress of the httpd-proxy-scoreboard
> branch; maybe there's some work in there that would apply to these issues.

It is a bit dormant for the moment.



View raw message