----- Original Message -----
From: "Costin Manolache" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <dev@tomcat.apache.org>
Sent: Friday, November 25, 2005 11:25 PM
Subject: Re: svn commit: r349085 -
/tomcat/sandbox/java/org/apache/tomcat/util/net/NioEndpoint.java
On 11/25/05, Bill Barker <[EMAIL PROTECTED]> 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
AjpAprProcessor.
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.
Costin
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
