On Mon, Aug 16, 2010 at 2:28 PM, Andrew Oliver <[email protected]> wrote: > Note that it is an option, not a default setting. The problem with > the heartbeat bit which Red Hat/JBoss use is the unstandardized > proprietary protocol required (http://jboss.org/mod_cluster) with > separate logic to manage it.
No, in 2.3/trunk, there is a bundled module to provide this in httpd: https://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/cluster/mod_heartmonitor.c https://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/proxy/balancers/mod_lbmethod_heartbeat.c > The problem with the status url is that it doesn't accomplish the same > thing nor is it that very manageable with multiple contexts (i.e > http://server1:8080/foo http://server1:8081/bar ...). You'd have to > make a separate request each time. > > Purpose: > > C = Browser > P = middle apache server > W = destination web server (probably tomcat) > > C------>P------->W > > C asks for http://myserver/someDatabaseBackedThing > P matches and forwards this request to W with the expect continue and > specified 5 sec expect-continue timeout. A separate overall proxy > timeout of 1 minute is set. > W returns a continue but then begins to process the request > (CGI/JavaServlet/PHP whatever to the database) > W spends less than a minute and the request is successful > > C asks for http://myserver/someDatabaseBackedThing > P matches and forwards this request to W with the expect continue and > specified 5 sec expect-continue timeout. A separate overall proxy > timeout of 1 minute is set. > W does not return a continue or any kind of response for 5 seconds > P marks that worker dead meat > > C asks for http://myserver/someDatabaseBackedThing > P matches and forwards this request to W with the expect continue and > specified 5 sec expect-continue timeout. A separate overall proxy > timeout of 1 minute is set. > W returns a continue but then begins to process the request > (CGI/JavaServlet/PHP whatever to the database) > W spends more than a minute and the proxy request times out > > The case of a dead connector things back out rather nicely and its > clearly distinguishable from a bad script. > > -Andy > > On Mon, Aug 16, 2010 at 2:52 PM, Jim Jagielski <[email protected]> wrote: >> >> On Aug 16, 2010, at 1:42 PM, Paul Querna wrote: >> >>> On Mon, Aug 16, 2010 at 8:30 AM, Jim Jagielski <[email protected]> wrote: >>>> >>>> On Aug 16, 2010, at 10:56 AM, Plüm, Rüdiger, VF-Group wrote: >>>>> >>>>> This basicly sums up the downsides of this approach I see as well. >>>>> >>>>> IMHO to avoid a spec violation we can only add the Expect header to >>>>> requests with request bodies. OTOH these requests hurt most when they >>>>> fail as we cannot sent the request body for a second time, because >>>>> we do not have it any longer available in most situations and requests >>>>> with request bodies are usually not idempotent. >>>>> >>>>> On the second issue we only need to take care that we do not add something >>>>> already there and remove something that client expects to see. >>>>> >>>>> One last thing I see is that this only works if the backend is HTTP/1.1: >>>>> >>>>> 8.2.3 >>>>> >>>>> - If the proxy knows that the version of the next-hop server is HTTP/1.0 >>>>> or lower >>>>> , it MUST NOT forward the request and it MUST respond with a 417 >>>>> (Expectation Failed) >>>>> status. >>>> >>>> Yes, the code itself is aware of the limitations of 100-Continue, >>>> including version and req body considerations... It's not ideal, >>>> but it's better than the OPTIONS method which I played around >>>> with earlier... >>>> >>>> Still I think it's useful to add it in, have it disabled by >>>> default, and see how far we can take it... >>> >>> I think the only options really are a status URL, with a regex match, >>> so you can test if the backend has an expected content, and having the >>> backends advertise/notify the proxy that they are alive. >>> >> >> Well, OPTIONS is the defacto "HTTP ping" but it's also considered >> a "request" (afaik), and so things like keepalives, etc matter. >> That was the issue I ran into is that checking with OPTIONS >> doesn't totally remove the problem, esp for non-keepalive >> connections or one-shots, and then you need to worry if that >> last OPTIONS forced a connection that was in keepalive mode >> to close and all that junk.... >> >> What I just committed is not the ideal solution, but like you >> said, the real way to do this is non-trivial with the current >> architecture... >> >> >
