IMHO, the main benefit of non-blocking io has to do with improved robustness. If a router or adapter goes off the air while you're in the middle of a 'blocking' read, you are likely to never to see the light of day.
This problem is exacerbated for client-side development because it is 'difficult' to set SO_TIMEOUT on a URLConnection. Actually, it's impossible, unless you provide your own URLStreamHandler. And this requires that you start reading sun's java.net source code. Just my two cents. Tom Drake ----- Original Message ----- From: "Remy Maucherat" <[EMAIL PROTECTED]> To: "Tomcat Developers List" <[EMAIL PROTECTED]> Sent: Tuesday, January 08, 2002 8:35 AM Subject: Re: nbio connector | > 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]> | | | -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
