tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From kharp...@oreillyauto.com
Subject Re: Modify HTTP status returned by stopped context
Date Tue, 19 Jun 2012 19:07:39 GMT

*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, kharper2@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message