*resending this to group, as it has been about 3 hours and isn't showing up yet on list*
Hello Chris, > No, the webapp is selected first, then the path is trimmed (if > necessary) and then the longest-match wins when matching against > url-patterns configured in that webapp's web.xml. ... > Sorry, longest match wins for URI matching once the webapp has been selected. Makes sense. I wanted to make sure I was following the logic correctly. > There was a recent bugfix to TC 7[1] to fix something > related, but that was during redeployment and I suspect that if the > webapp is stopped you'd get some other behavior. I think I read about that bug fix in TC7. I believe it changed threads to paused when a context was reload/restarting or something like that; instead of sending a 404 immediately, if I recall correctly. > I tend not to stop > webapps so I've never bothered to play around with it. The two scenarios that lead me to all of this in the first place were dead applications (crashed web apps) and situations where a WAR is experiencing problems and must be stopped for some period of time (possibly because back-end resources are unavailable or whatever). The former is, sadly, more frequent than the latter. > No, this is definitely the place to have this discussion. Here's a little back-story to help understand my approach: I have a few web servers (apache httpd) sitting in front of a handful of application servers. The web servers are currently configured to use a single Proxy Balancer with a few Balancer Members for each "cluster" of tomcat servers. Tomcat has, of course, been configured to replicate all sessions in each cluster. I can drop app nodes left and right and as long as 1 is still up, requests still get serviced. The problem here, is that if a single server has an application crash Apache will continue to send requests through that Balancer Member resulting in intermittent "404"s for people. Here's where the "magic" I am attempting to setup comes in... Assuming Tomcat will return HTTP 503 for a crashed/stopped application, I can tell Apache to "failonstatus" 503, which will put the worker thread for the Balancer Member into the error state for a while, thereby preventing that server from being used. The problem this causes is, if even 1 application crashes or needs to be stopped on all servers, then all servers in the cluster will be marked unavailable by the BalancerMember thread and no other apps in the cluster will serve requests. To fix this, I take it one step further, by creating an entire Proxy Balancer for *each* web application and the Balancer Members are now on a per-context basis, so to speak. So when /foo crashes on "tomcat1" the BalancerMember entering the "error" state only affects requests to the foo context on the "tomcat1" server. I haven't seen anyone set it up like this exactly, but it sure seems like a really, really good way to achieve High Availability on a granular level. And as I read through the apache httpd docs and learned about Tomcat's clustering, I figured this was all an intentional design philosophy for others to follow. So I was certainly confused when I saw Tomcat returning 404 for things it could "find", but were "unavailable". I had one person report that WebSphere returns 503 for applications turned "off", and I read an old article that JBoss does the same; I have no direct proof of either. So I'm wondering if they've tried to do with their packages what I'm trying to accomplish with Apache httpd and tomcat. Thoughts? Kyle Harper -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kyle, On 6/19/12 9:26 AM, kharp...@oreillyauto.com wrote: > "Where did you configure this? Which webapp's web.xml?" In the ROOT > context (/). I'm on Ubuntu 10.04 with defaults, so > /var/lib/tomcat6/webapps/ROOT/WEB-INF/web.xml Ok. > "Yes, the longest match should win." We keep saying "the longest > match should win", but looking at the configuration it seems > illogical. If I configure the following: ROOT context: /foo/* > (My special servlet) foo context: / (DefaultServlet) Sorry, longest match wins for URI matching once the webapp has been selected. The webapp is selected using the left-most part of the path, with ROOT being the fall-through case: if you have /foo deployed and /foo in ROOT, I would expect your /foo webapp to receive the request. It's clear that's happening even from your failure cases. > Based on my testing this isn't the case. So is it accurate to say > tomcat's logic is (or we expect it to be): 1. Look for a context > that matches the URL base pattern. 2. If not found, search all > contexts for servlets with URL patterns that can service the > request and select the one with the longest match. No, the webapp is selected first, then the path is trimmed (if necessary) and then the longest-match wins when matching against url-patterns configured in that webapp's web.xml. > As for testing on 6.0.35 and 7.0.28, yea I can do that. I'll set > all that up and submit a bug report if I can't get the intended > behavior to work. But this bring up another point: wouldn't it be > more accurate for tomcat return HTTP Status Code 503 for a context > that has been deployed but is in the stopped/errored state? > Strictly speaking, it isn't "not found" but rather "unavailable". It's not really clear to me from the spec what to do about a "stopped" webapp that is still technically deployed. I'm not sure if Tomcat differentiates between a stopped webapp deployed to /foo and no webapp at all for /foo. There was a recent bugfix to TC 7[1] to fix something related, but that was during redeployment and I suspect that if the webapp is stopped you'd get some other behavior. I tend not to stop webapps so I've never bothered to play around with it. > If there is a better forum/group to have this discussion with let > me know. No, this is definitely the place to have this discussion. Thanks, - -chris [1] http://issues.apache.org/bugzilla/show_bug.cgi?id=53024 -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/gnvgACgkQ9CaO5/Lv0PBVDACgmH/cm8k2zOagH7Qprh7Mxd0Q LNIAoKTiBBFQDrpktd0THnwNo3t6t+Bk =QpwI -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. This communication and any attachments are confidential, protected by Communications Privacy Act 18 USCS ยง 2510, solely for the use of the intended recipient, and may contain legally privileged material. If you are not the intended recipient, please return or destroy it immediately. Thank you. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
