On Mon, 1 Oct 2001, Aaron Bannert wrote: > > 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.
I know - anything that has a security-constraint ( or filter for 2.3 ) has to be sent to tomcat, since authentication is not integrated (and filters are ... well, nightmares ). Even for normal static pages - the apache configuration to do that is quite complex - and I'm not only talking about users, but for us too. Generating the config or sending it via wire does simplify the user's life, but the problem is that we have many unsolved problems. > > 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. Well, I was just stating the current reality - of course tomcat should take advantage of this. Integrating with the large collection of modules is one of the big benefits of in-process - and it's a 2-way street. The only problem - it's not yet completed, and there are many problems due to 'impedance mismatch'. > > 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. No, the point is that tomcat can use JNI to access the httpd internals _like_ any other apache module. Most of the 'internals' are not designed for remote access ( i.e. low latency, etc ) via IPC. > 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) No java code should be able to segfault the VM - regardless of what you do inside ( except for calling JNI - but that's not available to users, it's just a small layer in tomcat's internal implementation ). If you get a recent VM - you shouldn't have crashes ( at least it's a long time since I got a crash - and that was in a GUI application ). Of course, everything has a price - and it's important to have multiple choices :-) And you can configure jk for something in the middle - like use JNI for the most accessed pages and IPC for everything else. Or just use IPC for pages - but JNI for integration ( i.e. authentication, etc). Costin
