> I don't think I conflict with this requirement. In fact, > to execute a servlet's service() method still requires > a separate thread. In my design, the connector first reads > the request line and the headers in a non-blocking fashion, > naturally multiplexing up to 63 requests on a single thread. > I have a working HTTP processing state machine for that. > (You simply HAVE to write state machines in nb world, since > you can't encapsulate the algorithm in a single-thread linear > flow of methods because of multiplexing). Then it buffers the > whole request body using multiplexed non-blocking code. This > buffering is done using a special non-blocking pipe (more on > this below). After that, it constructs the request and response > objects, and fires off container.invoke(req, resp) on a separate > thread. The response object also has a non-blocking pipe that > to the servlet masquerades as a ServletOutputStream. > All this is done with the goal of completely avoiding any thread > running container.invoke(req, resp) to EVER block on a socket read or write.
I'm a bit sceptical about the usefulness of the thing, then, since reading and parsing requests headers is by far the fastest part of the current connector (all this is coming from many OptimizeIt runs I did). The new connector should even be a bit faster for reading. OTOH, the output is extremely slow (not because it's blocking IO, but rather because of really bad char/byte conversion), and nbio won't help that. The GC problems of the current connector is also a very significant issue which would take away all the benefits nbio would bring. It's still very useful work as the final optimization for very high load scenarios. > With my design, you still need one thread/request but only for the > time required to process container.invoke() In the real world, the servlets and JSPs are the thing which take by far the most time to complete, so I'm not sure you wouldn't end up spending a lot of time in the threaded part. > 1. It needs JDK 1.4 to compile, and I believe Tomcat should not rely > on the not-yet-final 1.4 JDK. Find something else. We already have JDK 1.4 flags in the build process, so it's a very bad justification I'm afraid. > 2. My framework as it stands now is a generic framework > for implementing arbitrary TCP/IP services in a non-blocking fashion. It is an extension of nio from JDK 1.4 then ? > 3. It would be tedious for me to send in CVS patches over long run. If your contributions are valuable, you would get commit access very quickly, but it's up to you. > If the Tomcat HTTP connector comes to life as part > of the nbserver project and works fine, I'll have no > objections to migrating it into Tomcat source tree. > In fact, since I'm publishing the code under Apache-style license, > I *CAN NOT* have any objections if it ever gets transferred into Tomcat source tree - > either with or without my assistance. :-) That's not true that way. The ASF wants the copyright on all code in its repositories. SO you're free to take our code, but we can't take yours without you donating it. Remy -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
