Hey Mark, Thanks for the information and quick response!
The typical use case is either during a hot redeployment of an application; we don't use the application context versions only because we had issues with it in the past, but the last time I tried it was years ago. If I remember correctly, the problems might have been classloader issues or related to JMX conflicts. For that reason, we redeploy using the same context and version. When the redeployment happens using the same context version, there is a small window where the app is stopped during the redeployment. The other case is on rare occasions, we will need to stop just one application deployed on a Tomcat node to troubleshoot something where clustering is making it more difficult to debug. We don't want to take down all the apps or the entire Tomcat node because we need it to handle the load. We don't hot deploy often, so it's not a huge issue, and even more rarely do we run into issues in production where we need to stop just one app, but it has happened. It would just be nice not to have to go tell mod_jk that a node was down for an application or have to stop Tomcat to get it to not send requests to a stopped app, if it was stopped and threw a 503 it would just happen. The only reason I even looked at this is that I've been tasked with implementing a comprehensive solution for handling all the different error conditions properly and displaying the proper error pages. We are also implementing a way to put all our applications in a "Down for Maintenance Mode" without having to stop them and that can be scheduled at the individual application level. I'll look at using a valve if we decide it's a big enough issue. Thanks again for the explanation! Dan On Wed, Jun 14, 2023 at 2:32 PM Mark Thomas <ma...@apache.org> wrote: > On 14/06/2023 19:49, Dan McLaughlin wrote: > > Hello, > > > > 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 > that way. > > 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? > > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- *NOTICE:* This e-mail message and all attachments transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure, or distribution is strictly prohibited. The contents of this e-mail are confidential and may be subject to work product privileges. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
