DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25596>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25596 Application briefly unavailable when using manager to reload ------- Additional Comments From [EMAIL PROTECTED] 2004-01-22 01:20 ------- Remy, I would be happy with your last response (use clustering if not dropping requests across application reloads is important), but unfortunately this does not always work with Tomcat 5 as it is now. Currently the documented method to cluster Tomcat is to setup multiple Tomcats behind Apache using mod_jk. However, mod_jk does not know when a Tomcat context is reloading any better than the HTTP connector so you end up with Tomcat returning "HTTP/1.1 400 No Host matches server name <servername>" and dropping requests. It takes some extra work to reload without dropping requests. The work around I have worked out to gracefully reload a node without dropping requests I have found at this point is as follows: * Enable session replication / clustering * Load balance Tomcat under Apache using JK * Modify JK config (workers.properties) and remove the Tomcat node to be reloaded * Gracefully restart Apache (requests will stop going to the Tomcat node to be reloaded * Reload Tomcat node * Re-enable Tomcat node in JK config * Gracefully restart Apache If we are sticking with the WONTFIX on this issue (I did see you post some future ideas a few days ago about Tomcat 5 refactoring which may cover this issue) I could write up a Tomcat/JK clustering HOW-TO which details the method I outlined above for addition to the current Tomcat documentation. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
