DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=29208>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=29208 start listening on port after everything has been initialized. ------- Additional Comments From [EMAIL PROTECTED] 2004-06-13 15:18 ------- I agree with Remy and Yoav that tomcat should start responding to requests as soon as possible - at least for tomcat standalone. The right solution for webapps that take a long time to initialize or for webapps that are beeing deployed at runtime and are in initialization state is to imediately send a temp error code (app not ready) to the client. What tomcat is doing today is clearly broken - but the current patch is broken too. At least for load balancing cases the patch is less broken than tomcat - when you have 10 tomcats in working state and you restart one, you don't want the restarting tomcat to hold requests until it is completely initialized, regardless of how long it take. Moh - a workaround for your servlets would be to have the init code spawn a thread and do the long-running operation in background. This will allow tomcat to start quick - and you can control what happens with requests received before the init is ready - for example send "try again later" pages. I think this should be the default behavior for tomcat, but patching this in tomcat is much more difficult. For load balancing - we need to make sure that the code is able to deal with this situation, and the dispatcher will either fail to connect to a worker or will get an error code "initializing" to tell it to try another worker that may be ready. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]