On Fri, Aug 6, 2010 at 3:54 AM, Rainer Jung <[email protected]> wrote: > On 05.08.2010 21:30, Eric Covener wrote: >>> >>> >>> http://people.apache.org/~rjung/httpd/trunk/manual/mod/mod_proxy.html.en#workers >> >> "A direct worker is usually configured using any of ProxyPass, >> ProxyPassMatch or ProxySet." > >> I don't know much about Proxy, but can this hammer home a bit more >> that these directives create a new worker implicitly based on [some >> parts of?] the destination URL? > > Good point. I updated the patch and HTML page to stress the identification > of workers by their URL. > >> And what happens when there's >> overlap? > > There's a warning box at the end of the Workers section talking about that. > I slightly rephrased it to also contain the trm "overlap". > > New patch: > > http://people.apache.org/~rjung/patches/mod_proxy_docs_workers-v2.patch
nits: + There are two builtin workers, the default forward proxy worker and the "built-in" + optionally included in a <directive module="mod_proxy">Proxy</directive> + directive. How about using "container" at the end instead of "directive"? (shrug) + ................. Direct workers can use connection pooling, + HTTP Keep-Alive and individual configurations for example + for timeouts. (dumb question: what's the diff between keepalive and connection pooling? reuse for one client vs. reuse for any client?) That last part sounds a little awkward. Maybe something like this: A number of processing options can be specified for direct workers, including connection pooling, HTTP Keep-Alive, and I/O timeout values. + ........ Which options are available is depending on the + protocol used by the worker (and given in the origin server URL). + Available protocols include <code>ajp</code>, <code>fcgi</code>, + <code>ftp</code>, <code>http</code> and <code>scgi</code>.</p> + The set of options available for the worker depends on the protocol, which is specified in the origin server URL. Available protocols include .... + <p>A balancer worker is created, if its worker URL uses no comma + <p>Worker sharing happens, if the worker URLs overlap. More precisely + if the URL of some worker is a leading substring of the URL of another + worker defined later in the configuration file. <p>Worker sharing happens if the worker URLs overlap, which occurs when the URL of some worker is a leading substring of the URL of another worker defined later in the configuration file. + In this case the later worker isn't actually created. Instead the previous + worker is used. The benefit is, that there is only one connection pool, + so connections are more often reused. Unfortunately all the configuration attributes + given explicitly for the later worker overwrite the respective configuration + of the previous worker!</p> This sounds like a discussion of pros and cons. There's no pro, since the user didn't intend to configure it this way, right?
