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. [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |INVALID ------- Additional Comments From [EMAIL PROTECTED] 2004-05-26 14:51 ------- You're right that initialization can take a long time and is not bound by the spec. But your patch has several flaws, and I agree with Remy in vetoing it. They include the following: - If one app initializes quickly, and another takes 2 hours, the quicker app is not available until the longer app is done initializing. This is not acceptable for most scenarios. - If the port is not available (e.g. another process is running on it), then all the initialization work is done for nothing. The current behavior asserts this quickly and doesn't waste time or processing cycles if the port is not available or the JVM is not permitted to bind to it. I'd type more but I have to run to a meeting. One suggestion off the top of my head for your monitoring concerns is to run the long-initializaing webapp on its own server, and define different monitoring criteria for that server or its cluster. The idea of binding and accepting requests on the port, instead of binding but not accepting, is intriguing. Discuss it further on the tomcat-dev list if you will, but not here please. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
