James,
On 3/7/23 16:09, James H. H. Lampert wrote:
(I have the general impression that APR is not an option on IBM Midrange
boxes, but I could be mistaken.)
It might be.
https://www.ibm.com/docs/en/ibm-http-server/9.0.5?topic=chs-apache-apr-apr-util-libraries-included-withibm-http-server
Are you running directly on AIX/xOS/whatever or are you running on a
Linux OS hosted by that stuff? I seem to recall at one point you at
least experimented with running Tomcat inside a Linux container.
If you have a compiler and toolchain, you can probably build APR and
then libtcnative.
For my money, you would only want to use libtcnative if the following apply:
1. You are terminating TLS in Tomcat. If you have clients connecting
directly to your Tomcat server, this *should* be the case. If you have
clients connecting through a reverse-proxy, load-balancer, etc. then
this *might* be the case. I would argue that traffic between a RP/LB
ought to be encrypted even if it's on a "trusted" network.
2. You have lots of traffic. This is subjective, of course.
Jean-Frederic has some metrics on JSSE-vs-OpenSSL but all comparisons
I've ever seen show OpenSSL beating the crap out of JSSE. In *some* JVMs
(I think all he tested), there were bugs which caused the JVM not to use
the local CPU's hardware-implementation of AES and other handy ciphers,
meaning that software was being used to perform the cryptographic
operations instead of hardware. This had a significant performance impact.
"Significant" is relative. If you get 10000 requests per day, this kind
of thing doesn't matter. If you get 100M, your opinion may change.
The rare bugs that do occur in APR and libtcnative can cause the whole
JVM to crash, rather then just throwing an exception saying "oops" and
allowing the server to continue. This is another consideration when
deciding to use libtcnative or not.
Using NIO+OpenSSL still uses libtcnative, but it is slightly safer than
using APR+OpenSSL just because there is even less native code involved.
Rémy's work with Panama in recent JVMs is exciting because it would mean
that libtcnative would no longer be necessary; Java would call OpenSSL
directly without the native-glue that libtcnative provides. OpenSSL is
probably far better-tested than libtcnative, so removing yet another
native component from the mix is a definite win.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
