On Mon, Oct 01, 2001 at 12:10:36PM -0700, [EMAIL PROTECTED] wrote: > On Mon, 1 Oct 2001, Aaron Bannert wrote: > > > What are the main advantages to using an in-process VM as opposed > > to an out-of-process VM bridged over some form of IPC (like > > mod_webapp/mod_jk/mod_jserv)? > > Well, using in-process VM ( like mod_jk ) has many more benefits than > just reduced request/response latency.
Agreed. > Think about mod_perl - it's not just about 'faster CGIs'. > > Right now the 'integration' between tomcat and apache is in a very > bad shape, the web server is used mostly as a proxy ( that adds a > significant overhead, apache+tomcat can be slower than tomcat standalone), > and to servle static files ( that are not password protected ). > Authentication can be done only by tomcat, and having apache send messages > to tomcat to authenticate for static pages would kill any performance. In many cases I've seen, apache isn't even being used to serve static content from the java webapps. OTOH, I think we could come up with a better way to map tomcat's static content to the virtual URI-space of apache to encourage this more. > In general, tomcat can't benefit from most of the features the web server > provides, and the web server can't benefit from any feature that tomcat > provides. I have to disagree with this. In general I think we're all much more comfortable using apache-httpd's HTTP parsing routines, if not merely for the fact that they are tried and tested (not to mention, in many cases implemented by the spec author). Tomcat can and should take advantage of this. In addition, the huge collection of httpd modules can be of huge value to tomcat. The biggest problem I'm seeing here is integration. > And the difference between a method call ( even via JNI ) and > IPC - it's pretty significant. But that's nothing compared with > the fact that via JNI you can avoid a lot of memcopy, use existing > ( and optimized ) methods, have access to a powerfull API, > hook deeply into apache. I agree that there is a potential bottleneck in remote IPC that can be avoided with things like JNI. However, I don't think that JNI has better access to the httpd internals than any other apache module. > > I would imagine request/response latency is reduced, but how well does > > it scale, and how does it deal with issues of robustness? > > It doesn't scale very well in a multi-process model, and it's as robust as > the Java VM. The main problem with multi-process model is the sessions. > But that can be resolved ( especially if you take advantage of mmap ), > and you still gain a lot from the deep integration. Apache 2.0 will offer a few alternatives to the multi-process (aka prefork) model, two of which are multi-threaded, multi-process models. You may want to look into this (perhaps having one multithreaded JNI-wrapper per process). If anything, the newer models will give you many more variables to play with. The concern I have with robustness of the VM isn't the VM itself, but the 3rd party jars that are used in most webapps. One of those modules causes a segfault in the multiprocess model and apache/tomcat just keep on chugging. If you have a segfault in one of the multithreaded models, you end up losing all the threads in that process -- even if they are in the middle of a healthy connection. (Apache will have this same problem, so it's not specific to tomcat) -aaron
