tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@clove.org>
Subject Re: Re: >> Apache/Tomcat Collaboration
Date Mon, 01 Oct 2001 17:34:24 GMT
On Mon, Oct 01, 2001 at 12:10:36PM -0700, cmanolache@yahoo.com 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

Mime
View raw message