The development branch (trunk) got more commits to reorganize the code
with the intention of putting an emphasis on the bridge design. The 2
existing bridges (prefork and worker) have been sided by a new bridge
named 'lazy' and as you may guess it allocates resources and starts new
threads only when demanded.
I remember how this proposal of a lazy policy was saluted by criticism
as some of us rather prefers to have upfront server processes ready to
serve requests. The lazy bridge it's not meant to replace the first 2
bridges. The main purpose was to implement an example made of simpler
code from which you may have a better understanding of the design. A
bridge module offers not just a way to adapt mod_rivet to a given MPM,
it can be used to implement different models of resource and workload
management.
Nonetheless the lazy bridge will be fully functional and it could work
better for development systems where server restarts are frequent. I
think that it could fit also into servers for a relatively broad class
of applications, but I won't try to push too much on this. Currently the
bridge automatic selection rule ignores this bridge and the
configuration now handles also a MpmBridge directive in order to have a
way to force a certain bridge.
The bridge selection rules work in this way
1) the environment variable RIVET_MPM_BRIDGE is checked and if
existing its value must be the full path to the bridge shared library
2) if the server configuration directive MpmBridge was set its value
is first tested as the full path to the library. If this file
doesn't exist then the value is interpreted as a single <word> and
composed into the path "RIVET_TARGET_DIR/mpm/rivet_<word>_mpm.so"
3) The current heuristic based on the MPM features is tested to
understand if we are running the prefork MPM
4) If everything fails the 'worker' bridge is loaded.
the lazy bridge creates no threads at server start up (and therefore no
Tcl interpreters are initially created). As HTTP requests come in the
request handler checks for idle threads, if no one is sitting on a
virtual host queue then a new thread is fired. By now there is no limit
posed to the number of threads and in order to give the bridge the
needed robustness this point has to be addressed. As such the lazy
brigde is still highly experimental.
-- Massimo
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
