----- Original Message ----- From: "Remy Maucherat" <[EMAIL PROTECTED]> To: "Tomcat Developers List" <[EMAIL PROTECTED]> Sent: 2002. január 8. 17:35 Subject: Re: nbio connector
> > 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 Unless the input comes in slowly due to network conditions, or a deliberate DoS attack attempt. A client that opens many connections and then supplies input one byte per minute will bog down many threads and can cause a DoS with a blocking connector. > > > 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. > I wasn't aware of the fact. This argument does not hold then, really. > > 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 ? > No. Having non-blocking sockets API is not yet a server framework. You still need to attend to many implementation details: output buffering (and the associated memory management), setting up threads that act as selector loops for accepting, reading and writing, creating and tearing down those threads as load rises/lowers (as it stands now in JDK 1.4, a single thread can manage up to 63 channels so you still need multiple threads, only less than with blocking approach), explicit key cancelling, etc. With the framework, the protocol implementor only has to implement a ProtocolHandlerFactory and ProtocolHandler interface, and need not be concerned with low-level connection management. The whole thing is not a rocket science, and is quite trivial AFTER I've spent several nights on trying out how nio works and resolving surfacing issues -- that's what I want the spare the fellow developers of. > 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. I see, that's really a distinction since in order for you to incorporate the code I have to transfer you the copyright. However, that's the consequence of the ASF policy and not of my licensing model (which is Apache-stlye itself). The "I'll have no objections to migrating it into Tomcat source tree." sentence still holds even if it means donating the code later on. Attila. > > Remy >
smime.p7s
Description: application/pkcs7-signature
