tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: [PROPOSAL] Tomcat 10: Drop APR Connector
Date Wed, 09 Oct 2019 19:40:06 GMT
Hash: SHA256


On 10/9/19 11:40, Michael Osipov wrote:
> Am 2019-10-07 um 16:39 schrieb Christopher Schultz:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>> All,
>> I recently gave a presentation on locking-down Apache Tomcat[1]
>> and I briefly discussed the "sharp edges" present in Tomcat. Some
>> of them are unnecessarily sharp and may be actually unnecessary.
>> I'm going to make a few proposals to remove functions from
>> Tomcat.
>> Proposal: Remove APR connector
>> Justification:
>> The APR connector was once used to provide superior I/O when
>> compared to the only other available I/O mechanism available in
>> Java: blocking I/O. Specifically, the APR connector allowed
>> Tomcat to wait for keepalive requests on a connection to in a
>> non-blocking fashion which was not possible with Java BIO-based
>> connectors.
>> The introduction of NIO into Java back in Java 1.4 (!!) changed
>> things, and NIO support was added to Tomcat in 6.0. Now that it
>> has had time to mature, the NIO connector is superior to the APR
>> connector in several ways:
>> 1. NIO connector allows non-blocking TLS handshakes 2. NIO
>> connector uses less (Tomcat-owned) native code
>> The first item improves performance and availability and the
>> second item improves stability (and thus availability).
>> The last advantage which (until recently) made the APR connector
>> still very useful was the ability to use the OpenSSL
>> cryptographic library for all cryptographic operations which is
>> measurably higher-performance than those typically provided by
>> the JVM.
>> This last advantage no longer exists since we have a JSSE
>> provider available for OpenSSL using libtcnative.
>> Notes:
>> This proposal does not recommend the removal of libtcnative. Only
>> the removal of the APR connector, the APR lifecycle listener, and
>> the associated native code required to support those components.
> Though, I have no opion for or against. It has worked very well for
> me for the last 10+ years on HP-UX for our software.

I'd love to get your feedback on NIO+OpenSSL, then.

> Do we have any numbers comparing performance of both for different
> loads?

Yes. All of Jean-Frederic's presentations[1] for the last few years at
ApacheCon conferences all have slides showing the performance comparison

> Are there any drawbacks not using the APR connector?

The only drawback I see from using NIO+OpenSSL is that CPU usage goes
up a bit. The APR connector is apparently (slightly) more efficient in
terms of CPU, but everything else seems to be just about the same --
such as throughput.

> OpenSSL must stay, it always works very well.

Whether or works or not isn't the issue. It's how well is performs.
(Well... once it's working.) OpenSSL is a requirement because most
Java cryptographic providers perform terribly.

- -chris

Comment: Using GnuPG with Thunderbird -


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

View raw message