Hello; I am an administrator for several websites. We are using Apache HTTP v2.2.9 as a front end to communicate with WebSphere 6.0 JVM's on the back end. This is all, typically, on Solaris 9. To meet some of the high availability requirements of our applications, we've been using the WebSphere plugin to perform the activities now available to mod_proxy_balancer (we've been a 2.0 shop for quite some time and are now migrating). Obviously, we prefer mod_proxy_balancer for two reasons (aside from the fact that it's not IBM). Primarily is the ability to use hardware engines with OpenSSL - which a certain vendor has yet to figure out. And secondarily because of the ProxyTimeout directive setting a minimum response time for the backend. In the WebSphere plugin, a buggy backend with even a hung webcontainer thread will sit and spin until the user just walks away from the site. My question stems from the behavior of ProxyTimeout. When the backend times out, a 502 is delivered to the user and the following error logged: [error] [client 172.19.106.35] (70007)The timeout specified has expired: proxy: error reading status line from remote server was4stl2 It seems there are actually three available timeouts for balancer memebers... time spent waiting for TCP ACK, time spent waiting for a connection to the backend, and time spent waiting for an available worker from the balancer. Unfortunately, it seems ProxyTimeout, which actually sets the amount of time the backend has to reply, can not be accounted for in the balancer itself. With that in mind, I did some rummaging around to see how I might be able to mark a backend out of service if the ProxyTimeout setting is exceeded, and then retrying the request on the other route. For reference, we intend to set this somewhere near 3 minutes to allow for particularly slow jobs like running reports and what not. My research, so far, has been a bust and I can not seem to find anything. I wanted to ask the group if anyone has experience with configuring HTTPD to behave as described. Some of the approaches I have considered are: *Configure an errorDocument for 502 that points to a rewrite rule setting an env flag for the failed route. Somehow mark that route out of service from there? This won't retry the request. *When a 502 is encountered, force a rewrite of the route marked in the stickysession cookie. Unfortunately, this won't mark the worker out of service, but will only direct the user to the other side on their next request. *Use environment entries to track known 502 backends and use the rewrite engine as a replacement for the balancer module (yea, that's nuts!). Thanks in advance for any sage wisdom -Daniel ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|