On Sun, 16 May 2004, Remy Maucherat wrote: | Costin Manolache wrote: | | > Remy Maucherat wrote: | > | >> Shapira, Yoav wrote: | >> | >>> One area to keep in mind there is performance. There's no argument on | >>> the utility of JMX at all. I also think most of the performance hit | >>> would be at initialization (and shutdown), as you're | >>> creating/naming/binding JMX operations/attributes. This is better than | >>> having a performance hit in the request processing pipeline, so we're | >>> OK, but it's nonetheless something to keep in mind as we're adding JMX | >>> instrumentation all over the place. | >> | >> | >> | >> AFAIK, the performance hit would be minimal (JBoss runs ok to me, so | >> JMX seems fast enough overall). It's an issue of cleaning the code, so | >> it's not useful by itself. I think Costin wanted to do that migration | >> to full JMX (we're a bit too much middle ground, and all those | >> listener interfaces are definitely not trendy these days ;) ). | > | > | > | > For the critical path probably it's good to keep using an interface, but | > for all "container changes" and other notification - there is no | > performance issue. | | Yes, but we can't be too bad either: if we take one minute to deploy a | webapp (unless we're precompiling on deploy ;) ) then it would be bad.
The startup-time of Tomcat is -really- annoyingly slow..! So if you'd need some user/developer-type-user feedback: shorten the startup time! One -often- restarts tomcat when developing stuff - the redeploy stuff isn't always totally cool - then you'll have to wait "forever" for Tomcat to start. Another thing I'd love to see, which I probably at one point'll make myself if it doesn't get done (but I've been surviving for 4 years w/o so far, though!), is: The shutdown-thingy. When one invoke the remote shutdown procedure, it releases immediately after getting "the packet" out the door, not waiting a nanosecond for tomcat to actually shut down. I'd like to see the remote shutdown process (the java-thing) wait all the way till Tomcat actually has shut down, or -most probably- have shut down. This could be done in the following manner: the shutdown process will hook up to Tomcat, and send the shutdown-packet. It would then wait for the "shutdown done" packet. Tomcat would start shutting down, and -right before- it invokes System.exit(0), or the main terminates, it'll send the "shutdown done" packet. The shutdown process would then -wait- (sleep) 30 millis before exiting. This would ensure that any context-switching that needed be done at that time would be done (Thread.yield() does -not- actually yield the processor (at least not on Linux w/ sun java)! But sleeping some millis -does- yield! (try it!)), so that the Tomcat java-process actually exists, and then we'd go back to the shutdown process, and that'll exit. There are plenty of annoyances with the existing system, but most notably, is the init.d-shutdown-style scripting of most Unix-style Os'es (and most probably also with Windows): you can't be sure if the Tomcat process actually have exited at all when you shut down the machine - risking the abrupt termination of some important shutdown procedure for some of the webapps. Another good idea would be the possibility to use the Tomcat control class to poll that Tomcat -is up-, for the "other way around": when a system -starts-, you often can't continue with some things before some other things are ensured that have started. So the control-code could be invoked with "-ensureUp" or something, that would continously try to connect to the Tomcat process and get the "I'm up and running with all the initial webapps" acknowledgements. This would enable a startup script to first fire off a java-process with Tomcat -in the background-, then immediately afterwards fire off the control java-process with "-ensureUp" -in the foreground-. This would exit immediately when Tomcat actually is up, so that you could exit the control-shellscript or whatever. -- Mvh, Endre Stølsvik M[+47 93054050] F[+47 51625182] Developer @ CoreTrek AS - http://www.coretrek.com/ CoreTrek corporate portal / EIP - http://www.corelets.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
