Ideas? Yes, and it's very simple - use fork()! Obviously this is not going to work on Windows, but for the case of Java hosting, we largely don't care.
Let's put this in perspective. Quite a few hosting providors (mine included) run PHP in CGI mode. Any less expensive solution is competitive. The notion is very simple. Load a single master instance of the JVM. Pre-load lots of common classes (a list customized by the hosting service). Pre-initialize lots of classes (again a customized list). When a user request comes in, fork() a copy of the master instance (including possibly a chroot()). The child then processes the request and exits. The master instance basically does nothing but sit around and wait for fork() requests. Assuming that fork() on your version of Unix has a good implementation of copy-on-write (something I have not been able to verify easily), then the incremental real memory use should be *very* small. You have to consider how (or if) to allow for long-running background threads. Successive requests for the same user will not use the JVM (whether this counts as an advantage or disadvantage is debatable). The JVM isn't going to be optimizing code. But you get excellent isolation, no concern over memory leaks (and other left-over cruft), and you should (vastly) out-perform PHP in CGI mode. On 4/6/06, Remy Maucherat <[EMAIL PROTECTED]> wrote: > > Hi, > > This thread started (for whatever reason) on the private list as part of > an unrelated discussion. The point is to see what could be improved to > make Tomcat more suitable for shared hosting, which is a very nice goal, > but unfortunately with very serious issues. > > I don't see many improvements possibilities, as I consider the following > solutions and problems (where each user would at least need its own > vhost): > - Every virtual host gets its own appBase folder. Having its own folder > for JARs just won't work (or it means you were able to use the "shared" > folder successfully, which I doubt). If you use the > TOMCAT_HOME/TOMCAT_BASE stuff, each user can get its own "shared" folder. > - There are still tons of JVMs to manage and monitor, which may be a > problem. > - If the connector should be shared, with the servlet containers running > in separate processes, I don't see how to cross the process barrier > except by going back to square one (httpd in front, with AJP and many > JVMs/Tomcats, each with its own vhost). > > Some general problems for production are: > - No self tuning of the JVM. > - No actual isolation, throttling capabilities, etc, provided by the JVM. > - Impossibility to control memory leaks (impossible to force discarding > classloaders and all associated class defs and instances, for example). > - Hard to do thread management (by that I mean, monitor and recover for > threads stuck in loops or deadlocked). > > Any ideas ? > > I suppose native code could be used to improve the situation in some > areas (although I don't know how to do it ;) ). > > Rémy > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
