tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Attila Szegedi" <szege...@freemail.hu>
Subject Re: nbio connector
Date Wed, 09 Jan 2002 09:52:23 GMT

----- Original Message ----- 
From: "Remy Maucherat" <remm@apache.org>
To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
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
> 


Mime
View raw message