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-05-26 15:16 -------
> - 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 I'm reading the code correctly, this is not true: the StandardService
implementation starts all it's containers (and therefore the contexts) before it
starts the connectors. see StandardService.start(). In other words, when a
single app that takes 2 hours to initialize, *all* applications are waiting for it.

> - 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.

This is not a serious concern in a production environment. You can be sure that
when a server takes 2 hours to load, a lot of checks and balances are in place
to make sure it will boot properly. Besides, for servers that boot quickly, the
time difference is not a problem anyway.

> One suggestion off the top of my 
> head for your monitoring concerns is to run the long-initializaing webapp on 
> its own server

That's already the case, but it still doesn't help the fact that the socket is
bound and hangs every incoming call.

Would it be alright if I changed this to a request for enhancement and we made
this a parameter to the connector?

Thanks
Moh

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to