On 14/06/2023 19:49, Dan McLaughlin wrote:
This is probably a question that would be better suited for the dev list,
but I thought I'd start here first.
That depends. It is generally better to start on the users list.
Does anyone understand the reasoning behind why Tomcat, when clustered,
throws an HTTP status 404 and not a 503 when you have an application
deployed but stopped or paused?
The issue you describe only affects stopped applications. If an
application is paused then any requests to that application should be
held until the application is unpaused (or the client timeouts out).
The current Tomcat Mapper dates back to at least Tomcat 4. It might be
earlier but I don't know the Tomcat 3 code well enough to find the
Tomcat 3 mapping code in the web interface and I'm not curious enough to
check the code out so I can use grep.
The clustering implementation dates back to Tomcat 5.
You'll need to dig through the archives to see if this topic was ever
raised and, if it was, the result of that discussion. Probably around
the time clustering was added.
I think I understand that my only option is to
failover for 404s considering the current implementation.
That might cause problems. If the node returning 404 is marked as down
you'll have a DoS vulnerability that is trivial to exploit.
I've looked to
see if there was a configuration setting related to clustering that would
allow me to change the behavior, and I couldn't find one; the only solution
seems to be to write a custom listener that detects that an application is
deployed but stopped or paused, and then throw a 503 instead.
That would be a better short-term solution and fairly simple to write.
I'd probably do it as a Valve as you'll get access to Tomcat's internals
The clustering implementation generally assumes that all applications
are available on all nodes. If that isn't the case I wouldn't be
surprised to see log messages indicating issues with replication.
What is the use case for stopping one (or more) web applications on a node?
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org