tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Luc Rochat <j...@cybercable.fr>
Subject Re: Discussion: AJP next
Date Tue, 01 Feb 2000 22:04:45 GMT
costin@eng.sun.com wrote:
> 
> >  The getRealPath callback is a good example for something that may be a
> > problem, not because of the callback that we will have to do but because
> > of the servlet APIs. We have getRealPath in two places - the request and
> > the context objects, we can use a callback only during a request, how are
> > we going to resolve the difference? Same thing applys when we want to map
> > a suffic to a mime type using the web server.
> 
> It's a problem only if tomcat will call getRealPath outside of request
> processing. It's a very special case - most of the time it's a servlet
> that calls the methods, and the servlet is executed as a result of a
> request ( i.e. you have an open communication). Doesn't matter if Context
> or Request is called for realPath - the implementation of the method will
> just send a message to Apache and get the response.
> 
> In the special case, when you have a non-servlet thread calling back, you
> can do some tricks ( like a HTTP connection back to apache ?), but again,
> it's not the normal case and probably will not happen too much ( so we can
> have something complex for this case ).
> 
> > > 1. Apache starts and open a connection with tomcat ( that will remain open
> > > for the live of the httpd process - avoid TCP open delay/request). Tomcat
> > > thread will be blocked on read, waiting for apache message.
> > >
> >
> >  Actually, since (sadly) Apache is multiprocess and can open up to 256
> > processes, one socket for the duration of the process is too much.
> >
> > Also such policy opens the door for denial of service attacks.
> >
> > I though that we should keep the connection open long enough but not for
> > the duration of the process. Not if we are going to allocate a tomcat
> > thread per connection.
> 
> Opening a TCP connection is slow, probably we can open it at first request
> to a servlet and close it after a while.
> 
> DOS can happen anyway - I don't think 1 connection/request is a solution.
> 
> ( also, TIME_WAIT is a big problem sometimes!)
> 
> We can discuss that more, but it's not so important - it's easy to make it
> optional.
> 
> > > I don't know how do you plan to deal with callbacks ( from a thread point
> > > of view ), everything else is fine in your proposal, but I think
> > > callbacks need to be addressed and explained better.
> > >
> >
> > I am going to deal with them similar to your description... I was also
> > thinking about writing some native code on the tomcat side so I will be
> > able to use select (no select in Java !!!). This way I can reduce the
> > number of Java threads and leave more connections open for a longer time.
> 
> I don't know if it's a good ideea - it will be benefical for high-loaded
> sites ( where you have a large number of concurent connections, that mean
> milions of hits/day ) - in this case load balancing is much better ( and
> using more boxes). Also, JNI and Invocation are faster and probably a
> better way to spend the time.
> 
> Costin
> 

At that point I'll try to give my opinion and possibly offer some ideas.
This topic has been one of the problems that have not been addressed in
Jserv, but we tried to imagine solutions. I am happy to see that a lot
of my previous ideas are expressed by others, and we are here only
missing some glue, which I hope I could contribute to bring.

1 - integrating a JVM in an Apache module is a _bad thing_ (tm) IMO.
    . from the architecture point of view. (n-tier is better for
scalability than monolithic servers)
    . from the security point of view (small pieces of code means less
bugs, user permissions problems)
    . from the portability point of view (example: Apache runs very well
on BSDs. JVMs don't).

2 - Opening a TCP connection for each request brings an extra overhead.
    . connections should be reused if possible (keepalive feature).

3 - one socket / httpd process could be too much, especially if more
than 1 Apache send requests to 1 servlet engine.
    . sockets can be closed at any time by the servlet engine, so we can
use one socket/httpd

4 - sockets cannot be easily shared between httpd processes (on Unix at
least, and with Apache 1.x).
    . true if the servlet engine stops and restarts while the Apache
server is still up. (load-balanced configuration). So don't multiplex
data on one socket, or offer it as an optional feature.
    . asking for the Apache father to re-create the socket and re-fork
all the children would be a bad idea.

5 - Using any other protocol than ajpv11 is faster.
    . yes but ajpv11 brings everything needed. So keep the "verbose"
protocol a possible choice.(for ben-ssl/mod_ssl by example).
 
6 - Callbacks to Apache are not mandatory. Or maybe they are. or will
be.
    . let's keep the protocol pluggable, so we can change it.

7 - All of this has to pass firewalls (callbacks ?)

8 - This protocol implementation should allow the basic load-balancing
mechanisms used in JServ, take care of keepalive enabled sockets,
authentication, without problem.

The solution seems to split the initial problem in 2 parts :
1 : the keepalive feature.
   . every httpd opens a socket -> one servlet engine (default server if
load-balanced config)
   . the socket is not closed by the httpd. it is reused and reused.
   . if the socket is closed by the servlet engine, httpd opens a new
one when needed.
   . the servlet engine accepts incoming connections from httpd
processes (belonging to 1..n Apache servers)
   . once accepted, a thread block on the socket to read new requests
(keepalive). 
     authentication is performed once, and the load-balancing parameter
(the servername to add to the cookie) is sent once.
   . if a servlet engine whishes, some of the opened sockets can be
closed.
   This should give a boost to performances, as the socket creation has
a huge cost.


2 : the new protocol (possibly) bi-directionnal protocol), built on top
of the the above keepalive enabled connections.
   . ajpv11 like. (not very clever, but everything is there).
   . ajpv21 like (with multiple packet exchanges in one single request
(yes, including requests servlet engine -> Apache).

Proposal :

Step 1 : I am going to start working on the keepalive feature, and will
bring C & java code ASAP. This will be tested with JServ, as I'm far
more familiar with the code.
This will be for Apache only (I don't care IIS, or NS for the moment)
and especially U**x, (I don't care NT/W95 for the moment).

Step 2 : see the code & talk.

Step 3 : protocol enhancements if people like it.

Feedback welcome.

Jean-Luc
http://ma-planete.net

Mime
View raw message