-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/08/10 12:13, Jeff Trawick wrote: > 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?
Can we have some examples put in that section - its a little wordy and I found it a little hard to understand, and I use mod_proxy quite a lot! Mark - -- Mark Watts BSc RHCE MBCS Senior Systems Engineer, IPR Secure Managed Hosting www.QinetiQ.com QinetiQ - Delivering customer-focused solutions GPG Key: http://www.linux-corner.info/mwatts.gpg -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkxb+FIACgkQBn4EFUVUIO2c8gCg1Qd2zkUxtvzMRAi1FrccaK0+ UXcAoOR/Nmle+KN0/PaIKTMGMo6DJkf1 =KyEK -----END PGP SIGNATURE-----
