tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <>
Subject Re: svn commit: r349085 - /tomcat/sandbox/java/org/apache/tomcat/util/net/
Date Sat, 26 Nov 2005 07:49:51 GMT

----- Original Message ----- 
From: "Costin Manolache" <>
To: "Tomcat Developers List" <>
Sent: Friday, November 25, 2005 11:25 PM
Subject: Re: svn commit: r349085 - 

On 11/25/05, Bill Barker <> wrote:
>> > The nio endpoint. Uses the thread pool. Only accept is implemented - 
>> > the
>> > polling of keep alive needs merging some code in the http11protocol.
>> >
>> Yup, it's still too incomplete to evaluate.  However from my work with
>> NIO/AJP, using blocking sockets after the accept will totally s*ck in
>> performance with NIO.  Unless you come up with something totally 
>> brilliant
>> :), I still agree with JFA that non-blocking sockets is the only way to 
>> go
>> with NIO.
>Well, I also agree that non-blocking sockets are faster than blocking.
>But as someone said, raw performance is not the most important thing
>for most people :-)
>My initial goal is to deal with the keep alives - i.e. not keep the
>threads busy for all the idle connections. That would be a nice
>improvement over the current non-nio connector, which can't do this,
>and is pretty minimal and consistent with the current model.
>I will eventually use the APR code for non-blocking parsing of the
>request. Not sure if in this endpoint or I'll try another one - I kind
>of like the fact that this code is very simple. I'm more interested in
>experiments with how to do non-blocking processing at coyote level,
>whatever happens in a servlet is limited by other factors - blocking
>socket is not the biggest overhead.

Urm, APR uses blocking sockets.  It uses APR to get around the fact that (at 
least with Sun's JVM) blocking NIO sockets totally s*ck.

Just look at the differences between the logic for ChannelNioSocket and 

>I'll announce when it's 'complete' or 'ready to evaluate' - right now
>it's just 'sandbox experiment'.
>Right now - there is little point in benchmarking.

This message is intended only for the use of the person(s) listed above as the intended recipient(s),
and may contain information that is PRIVILEGED and CONFIDENTIAL.  If you are not an intended
recipient, you may not read, copy, or distribute this message or any attachment. If you received
this communication in error, please notify us immediately by e-mail and then delete all copies
of this message and any attachments.

In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet
is not secure. Do not send confidential or sensitive information, such as social security
numbers, account numbers, personal identification numbers and passwords, to us via ordinary
(unencrypted) e-mail.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message