tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <>
Subject Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server
Date Thu, 30 Jun 2005 15:32:11 GMT

----- Original Message ----- 
From: "Remy Maucherat" <>
To: "Tomcat Developers List" <>
Sent: Thursday, June 30, 2005 3:39 AM
Subject: Re: cvs commit: 

> wrote:
>> billbarker    2005/06/29 19:49:38
>> With a 16K bufferSize, the APR connector is no longer the clear
>> winner in performance.  For BC, it's currently disabled by default,
>> but it's easy enough to change that after some more testing.
>Yes, I can see performance is better too. It's also possible that taking 
>the APR code, and rewriting it with regular Java IO would also yield 
>slightly better results (regular HTTP is still a little faster than APR 
>HTTP - some VMs make the difference very small, but the VM I use for 
>testing is definitely not the best for JNI).

Actually, on Solaris the big winner is ChannelNioSocket.  It wins the 
performance race easily now.  Too bad that NIO on Windows s*cks.  I guess 
that JFA was right, and non-blocking sockets is the way to go.

>Now that I've looked at it a lot, however, I dislike the Java AJP impl, as 
>it's way overengineered in comparison to what it required by the current 

Hey, I like the overengineering ;-).  Yeah, Costin got a little ambitious 
here before deciding to just use Coyote.  On the other hand, when Mladen 
wants you to implement unix sockets for AJP/APR, ChannelUn is going to start 
to look good ;-).


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