[PROPOSAL] Tomcat 10: Drop APR Connector

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

[PROPOSAL] Tomcat 10: Drop APR Connector

Christopher Schultz-2
-----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.

- -chris


[1] http://tomcat.apache.org/presentations.html#latest-locking-down-tomc
at
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl2bTg8ACgkQHPApP6U8
pFghUhAAwXEdrarxE5sgqMbZxswlOrRTQSIGZuh2t9KV8pJG+M8NrRbPMZxL3IX/
UkJA9JGxFGA20D9kn0Xx2eX276tKtW/ZyVhg9vvlKqm8+n+vXLuN/sj15sPw1f64
rCqj/GA+iMPP1AtBwc3E2bxBUI7WYGjgMutobwWOfHrlrw6/D4aNyO/t8XXlh9UT
ZcP9Nq0ed4G4I+zx+R//FmEa0Ky2ARUtiyuBhnA+yEFm0XT/iMpgGnl5DHpJ5nOv
U9YiTOU/bMXP1ABgCYoPgHPnYADKoEepdhD8x7CZTyUpR4vTr7DXxAABvapwynBo
sPb+CFjlQilS8zxNYbGZbCu/mpux88jKYvOrrf5Jjb8YzxAGmmy00VyzuyzApdLs
T9eYJazcej8u0he26U+QJi+HCQ+KpdSeMP/kQuw2BorvdD5BkPA22MvqoeIdU1Xs
IzS6+69/MwjkTSL3YOlxp/E7HuG/gegGYBgVphVVJVAYh5lyBcY9o5diTIwdbejU
yK+3WBbkK9dp8nM0GmKoaUqhLP/XvACG5FohW6P+EHLTjlCy7dPbr7s409coQb/1
JQqur4GABbM47MXSDaXHisXLSLY3RpF6Uo0Fb2AC2AuuAihjNpQ0GmeuLHhoPI7W
CycCLjMqLystoj8pNR1pil1FOgI1zOPilylpMX0mV5VuDhPxuFw=
=MZ7V
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Tomcat 10: Drop APR Connector

csutherl
On Mon, Oct 7, 2019 at 10:39 AM Christopher Schultz <[hidden email]> wrote:
-----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

I'm +1 for this
 

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.

- -chris


[1] http://tomcat.apache.org/presentations.html#latest-locking-down-tomc
at
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl2bTg8ACgkQHPApP6U8
pFghUhAAwXEdrarxE5sgqMbZxswlOrRTQSIGZuh2t9KV8pJG+M8NrRbPMZxL3IX/
UkJA9JGxFGA20D9kn0Xx2eX276tKtW/ZyVhg9vvlKqm8+n+vXLuN/sj15sPw1f64
rCqj/GA+iMPP1AtBwc3E2bxBUI7WYGjgMutobwWOfHrlrw6/D4aNyO/t8XXlh9UT
ZcP9Nq0ed4G4I+zx+R//FmEa0Ky2ARUtiyuBhnA+yEFm0XT/iMpgGnl5DHpJ5nOv
U9YiTOU/bMXP1ABgCYoPgHPnYADKoEepdhD8x7CZTyUpR4vTr7DXxAABvapwynBo
sPb+CFjlQilS8zxNYbGZbCu/mpux88jKYvOrrf5Jjb8YzxAGmmy00VyzuyzApdLs
T9eYJazcej8u0he26U+QJi+HCQ+KpdSeMP/kQuw2BorvdD5BkPA22MvqoeIdU1Xs
IzS6+69/MwjkTSL3YOlxp/E7HuG/gegGYBgVphVVJVAYh5lyBcY9o5diTIwdbejU
yK+3WBbkK9dp8nM0GmKoaUqhLP/XvACG5FohW6P+EHLTjlCy7dPbr7s409coQb/1
JQqur4GABbM47MXSDaXHisXLSLY3RpF6Uo0Fb2AC2AuuAihjNpQ0GmeuLHhoPI7W
CycCLjMqLystoj8pNR1pil1FOgI1zOPilylpMX0mV5VuDhPxuFw=
=MZ7V
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Tomcat 10: Drop APR Connector

markt
In reply to this post by Christopher Schultz-2
> 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

+1

> 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.

Yes, we'd need to keep that library going until at least 9.0.x is EOL.

There is then an argument for a new native library that simply wraps
OpenSSL (or ideally any OpenSSL clone). Project Panama may prove useful:
https://openjdk.java.net/projects/panama/

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Tomcat 10: Drop APR Connector

Rémy Maucherat
In reply to this post by Christopher Schultz-2
On Mon, Oct 7, 2019 at 4:39 PM Christopher Schultz <[hidden email]> wrote:
-----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

But it really didn't work then.
 
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).

I agree the OpenSSL native code used alone inside an OpenSSLContext is much easier to make crash proof than the network code as a whole in the APR connector.
 

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.

The APR lifecycle listener is not part of the APR connector, it initializes the libraries and sets config defaults based on that.

Anyway, +1 to attempt the APR connector removal.

Rémy
 

- -chris


[1] http://tomcat.apache.org/presentations.html#latest-locking-down-tomc
at
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl2bTg8ACgkQHPApP6U8
pFghUhAAwXEdrarxE5sgqMbZxswlOrRTQSIGZuh2t9KV8pJG+M8NrRbPMZxL3IX/
UkJA9JGxFGA20D9kn0Xx2eX276tKtW/ZyVhg9vvlKqm8+n+vXLuN/sj15sPw1f64
rCqj/GA+iMPP1AtBwc3E2bxBUI7WYGjgMutobwWOfHrlrw6/D4aNyO/t8XXlh9UT
ZcP9Nq0ed4G4I+zx+R//FmEa0Ky2ARUtiyuBhnA+yEFm0XT/iMpgGnl5DHpJ5nOv
U9YiTOU/bMXP1ABgCYoPgHPnYADKoEepdhD8x7CZTyUpR4vTr7DXxAABvapwynBo
sPb+CFjlQilS8zxNYbGZbCu/mpux88jKYvOrrf5Jjb8YzxAGmmy00VyzuyzApdLs
T9eYJazcej8u0he26U+QJi+HCQ+KpdSeMP/kQuw2BorvdD5BkPA22MvqoeIdU1Xs
IzS6+69/MwjkTSL3YOlxp/E7HuG/gegGYBgVphVVJVAYh5lyBcY9o5diTIwdbejU
yK+3WBbkK9dp8nM0GmKoaUqhLP/XvACG5FohW6P+EHLTjlCy7dPbr7s409coQb/1
JQqur4GABbM47MXSDaXHisXLSLY3RpF6Uo0Fb2AC2AuuAihjNpQ0GmeuLHhoPI7W
CycCLjMqLystoj8pNR1pil1FOgI1zOPilylpMX0mV5VuDhPxuFw=
=MZ7V
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Tomcat 10: Drop APR Connector

Rémy Maucherat
In reply to this post by markt
On Mon, Oct 7, 2019 at 4:59 PM Mark Thomas <[hidden email]> wrote:
> 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

+1

> 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.

Yes, we'd need to keep that library going until at least 9.0.x is EOL.

There is then an argument for a new native library that simply wraps
OpenSSL (or ideally any OpenSSL clone). Project Panama may prove useful:
https://openjdk.java.net/projects/panama/

Fun fact: Graal has a more radical way to replace JNI for accesses to native libraries.
So let's forget it, but still fun though.

Rémy


Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Tomcat 10: Drop APR Connector

Rainer Jung-3
In reply to this post by Christopher Schultz-2
Am 07.10.2019 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

+1 and +1 to the additional comments by Mark and Remy

> 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.
>
> - -chris

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Tomcat 10: Drop APR Connector

Michael Osipov
In reply to this post by Christopher Schultz-2
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.

Do we have any numbers comparing performance of both for different
loads? Are there any drawbacks not using the APR connector?

OpenSSL must stay, it always works very well.

Michael


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Tomcat 10: Drop APR Connector

Christopher Schultz-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Michael

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

[1] http://tomcat.apache.org/presentations.html
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl2eN5YACgkQHPApP6U8
pFjeSw//fTDGf9WnsSHHlyM4hZTmJaeg2PodguITTSytOopcPGBDjqm9lL0U2c+C
YtmMZfSQ659IQrSfKajJqAGINTRvSe/PViAKKFMW38v7tObkGZrQG6bfEj8zcnXS
jH5P2IoijTCS7nC7bJmrYoWIMN50BElynMzQ9BMQEIk39sqtOuJ270bJNI9fqtw9
zeB4lnMUv9BXliLtWdKFBH1dUOHbBJLFg3oSri5EI6CVZvbgkBlVZwAsfifQKrQF
B5NwEgJEamXZX+g7opwbx/+ePrZ9Jm3d94I2C5RoAtooVhkdVz/EpfcqX+EoYhbd
Ku8O/UbIZTqZgYj6qPB9Ow06M23VRbRWI6YC2FtSIoumjjt9OJBRgJhL/1E4etjQ
Hl/Nl+mS2kG5EOIvIDWyvubdunhOXmtdJEaVqtMBNzaqKYNfSUlJVcx/AUs8asP4
O6ajSfOWDJW3DLkin+CDARKgFpQ0B773MyVJ2DjfU0/9eMwO85r2UuWUinabImJm
l4gF70DPymXz4mrA0eRyRjNFSHPA7lj+a1X/vyIyn1nNztCfpbpwZwQYY9u+lJaP
TdtHBxbKqyl6wxvQYHGPCwvbjEPlECHviUvz1RJq7Ynf9GjI8TYLVaWBMSaE4mck
pXuB4KTznLW34XJ+ov3Mmyq2WeWWp+A4vnYNPL82oHPyfbU6vYE=
=sE0J
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]