Re: Objection to the deprecation of the tomcat-native/APR connector

[Mladen Adamović]

Perhaps for some users APR is significantly faster than NIO or NIO2, but
Graham Leggett didn't bring some examples like:
- company ZZZ reports 39% of higher CPU usage with APR for their project
- company XXX which is an Apache gold sponsor reports 43% of higher CPU
usage for APR for their project Lulu.

If the reason to keep it is that users need to change one line in the
server.xml is to keep it up, it could probably be done in the code
automatically switch to NIO if APR config is given. (sounds like an if-else
statement in the code).


On Thu, Dec 17, 2020 at 1:20 PM Rémy Maucherat  wrote:

> On Thu, Dec 17, 2020 at 12:12 PM Mladen Adamović <
> mladen.adamo...@gmail.com>
> wrote:
>
> > But what I have discovered from migrating from APR to Nio2 that our
> > processor usage went down. We never tried Nio2, I have setup APR back in
> > 2014 as I've read it has a better performance.
> >
>
> I would still say the APR connector is faster, just like the java.io
> connector was the fastest overall. But it can depend on what you are doing,
> maybe if your use case uses the poller more, then it could be significantly
> less efficient. The main problems are that it is crash prone (and it's
> expensive and complex to make it safe), and it doesn't have feature parity
> with NIO.
>
> About NIO2, Oracle has started updating and fixing NIO again. NIO2 is now
> lagging a bit in features (no inherited channel, no UDP - NIO just got
> fully rewritten support -, and now no domain socket support). The IO API
> war is not over yet though.
>
> Rémy
>
>
> >
> > So I don't see a reason why APR should stay as users can easily migrate
> to
> > NIO2...
> >
> >
> >
> > On Thu, Dec 17, 2020 at 11:41 AM Michael Osipov 
> > wrote:
> >
> > > Am 2020-12-16 um 16:38 schrieb Emmanuel Bourg:
> > > > Le 11/12/2020 à 17:56, Michael Osipov a écrit :
> > > >
> > > >> Well, isn't that really a OS vendor problem not ours? We can provide
> > > >> grace periods, but that's pretty much it. They need to solve that,
> not
> > > >> us on a volunteer basis.
> > > >
> > > > Note that (most) Debian Developers are volunteers too.
> > >
> > > This makes siauation even worse to sit on old version and continue back
> > > porting for downstream.
> > >
> > > >> FreeBSD's port of libtcnative is uptodate. I provide patches on
> > regular
> > > >> basis. Vendors like Debian or Red Hat lag years behind.
> > > >
> > > > I don't know the state in Red Hat, but in Debian tomcat-native is
> > > > up-to-date [1]. For the stable release there are backports with more
> > > > recent versions available.
> > >
> > > Thanks for the info, wasn't aware of that. Guess it takes the
> maintainer
> > > do that otherwise it will stick to very old versions.
> > >
> > > I am horribly surprised for RHEL 7:
> > > > $ yum info tomcat-native 2>&- | grep Version
> > > > Version: 1.2.23
> > >
> > > in contrast:
> > > > $ yum info curl 2>&- | grep Version
> > > > Version: 7.29.0
> > >
> > > This is unusable.
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> > > For additional commands, e-mail: dev-h...@tomcat.apache.org
> > >
> > >
> >
>

Re: Objection to the deprecation of the tomcat-native/APR connector

[Rémy Maucherat]

On Thu, Dec 17, 2020 at 12:12 PM Mladen Adamović 
wrote:

> But what I have discovered from migrating from APR to Nio2 that our
> processor usage went down. We never tried Nio2, I have setup APR back in
> 2014 as I've read it has a better performance.
>

I would still say the APR connector is faster, just like the java.io
connector was the fastest overall. But it can depend on what you are doing,
maybe if your use case uses the poller more, then it could be significantly
less efficient. The main problems are that it is crash prone (and it's
expensive and complex to make it safe), and it doesn't have feature parity
with NIO.

About NIO2, Oracle has started updating and fixing NIO again. NIO2 is now
lagging a bit in features (no inherited channel, no UDP - NIO just got
fully rewritten support -, and now no domain socket support). The IO API
war is not over yet though.

Rémy


>
> So I don't see a reason why APR should stay as users can easily migrate to
> NIO2...
>
>
>
> On Thu, Dec 17, 2020 at 11:41 AM Michael Osipov 
> wrote:
>
> > Am 2020-12-16 um 16:38 schrieb Emmanuel Bourg:
> > > Le 11/12/2020 à 17:56, Michael Osipov a écrit :
> > >
> > >> Well, isn't that really a OS vendor problem not ours? We can provide
> > >> grace periods, but that's pretty much it. They need to solve that, not
> > >> us on a volunteer basis.
> > >
> > > Note that (most) Debian Developers are volunteers too.
> >
> > This makes siauation even worse to sit on old version and continue back
> > porting for downstream.
> >
> > >> FreeBSD's port of libtcnative is uptodate. I provide patches on
> regular
> > >> basis. Vendors like Debian or Red Hat lag years behind.
> > >
> > > I don't know the state in Red Hat, but in Debian tomcat-native is
> > > up-to-date [1]. For the stable release there are backports with more
> > > recent versions available.
> >
> > Thanks for the info, wasn't aware of that. Guess it takes the maintainer
> > do that otherwise it will stick to very old versions.
> >
> > I am horribly surprised for RHEL 7:
> > > $ yum info tomcat-native 2>&- | grep Version
> > > Version: 1.2.23
> >
> > in contrast:
> > > $ yum info curl 2>&- | grep Version
> > > Version: 7.29.0
> >
> > This is unusable.
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: dev-h...@tomcat.apache.org
> >
> >
>

Re: Objection to the deprecation of the tomcat-native/APR connector

[Mladen Adamović]

Hi everyone,

TLTR: after switching from APR to Nio2 our processor usage went down.

Longer version:
Recently we had a production problem which was noticeable years ago, but it
became a real problem recently. In our tests 0.75% of connection requests
weren't served.
I have recently posted in Tomcat-Users email list thread "native connector,
server problems with "No data received"
after migrating from APR to Nio2 connector, the problem was still there.

It turned out that the upgrade from 8.5.5 to 9.0.41 solved the f..ine
issue (!), it is a pitty that bug existed in Tomcat for years even in 2014.

But what I have discovered from migrating from APR to Nio2 that our
processor usage went down. We never tried Nio2, I have setup APR back in
2014 as I've read it has a better performance.

So I don't see a reason why APR should stay as users can easily migrate to
NIO2...



On Thu, Dec 17, 2020 at 11:41 AM Michael Osipov  wrote:

> Am 2020-12-16 um 16:38 schrieb Emmanuel Bourg:
> > Le 11/12/2020 à 17:56, Michael Osipov a écrit :
> >
> >> Well, isn't that really a OS vendor problem not ours? We can provide
> >> grace periods, but that's pretty much it. They need to solve that, not
> >> us on a volunteer basis.
> >
> > Note that (most) Debian Developers are volunteers too.
>
> This makes siauation even worse to sit on old version and continue back
> porting for downstream.
>
> >> FreeBSD's port of libtcnative is uptodate. I provide patches on regular
> >> basis. Vendors like Debian or Red Hat lag years behind.
> >
> > I don't know the state in Red Hat, but in Debian tomcat-native is
> > up-to-date [1]. For the stable release there are backports with more
> > recent versions available.
>
> Thanks for the info, wasn't aware of that. Guess it takes the maintainer
> do that otherwise it will stick to very old versions.
>
> I am horribly surprised for RHEL 7:
> > $ yum info tomcat-native 2>&- | grep Version
> > Version: 1.2.23
>
> in contrast:
> > $ yum info curl 2>&- | grep Version
> > Version: 7.29.0
>
> This is unusable.
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: Objection to the deprecation of the tomcat-native/APR connector

[Michael Osipov]

Am 2020-12-16 um 16:38 schrieb Emmanuel Bourg:

Le 11/12/2020 à 17:56, Michael Osipov a écrit :


Well, isn't that really a OS vendor problem not ours? We can provide
grace periods, but that's pretty much it. They need to solve that, not
us on a volunteer basis.


Note that (most) Debian Developers are volunteers too.


This makes siauation even worse to sit on old version and continue back 
porting for downstream.



FreeBSD's port of libtcnative is uptodate. I provide patches on regular
basis. Vendors like Debian or Red Hat lag years behind.


I don't know the state in Red Hat, but in Debian tomcat-native is
up-to-date [1]. For the stable release there are backports with more
recent versions available.


Thanks for the info, wasn't aware of that. Guess it takes the maintainer 
do that otherwise it will stick to very old versions.


I am horribly surprised for RHEL 7:

$ yum info tomcat-native 2>&- | grep Version
Version: 1.2.23


in contrast:

$ yum info curl 2>&- | grep Version
Version: 7.29.0


This is unusable.


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Objection to the deprecation of the tomcat-native/APR connector

[Emmanuel Bourg]

Le 11/12/2020 à 17:56, Michael Osipov a écrit :

> Well, isn't that really a OS vendor problem not ours? We can provide
> grace periods, but that's pretty much it. They need to solve that, not
> us on a volunteer basis.

Note that (most) Debian Developers are volunteers too.


> FreeBSD's port of libtcnative is uptodate. I provide patches on regular
> basis. Vendors like Debian or Red Hat lag years behind.

I don't know the state in Red Hat, but in Debian tomcat-native is
up-to-date [1]. For the stable release there are backports with more
recent versions available.

Emmanuel Bourg

[1] https://tracker.debian.org/tomcat-native

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Objection to the deprecation of the tomcat-native/APR connector

[Michael Osipov]

Am 2020-12-09 um 14:36 schrieb Graham Leggett:

On 01 Dec 2020, at 14:09, Mark Thomas  wrote:


I also object to the removal of OpenSSL code, for the same reason.


It isn't being removed. The APR/Native library will be retained along
with OpenSSL support for the NIO and NIO2.

I expect the scope of the APR/Native library for Tomcat 10.1.x onwards
will be reduced to just those native methods required to interact with
OpenSSL which may mean removal of the APR dependency. If we can use
OpenSSL without any native code of our own (e.g. via project Panama or
similar) then better still.


I don’t see the logic here.

If the use of native code is a risk, then I expect to see use of openssl and 
any other API brought in by Panama avoided for the same reason?


We are in the middle of a global pandemic. Our users do not have the resources 
to suddenly divert to reengineering what is to them a perfectly working system, 
to replace what exists with something else that just works differently.


Upgrading to Tomcat 10 already requires significant re-engineering work
due to the java package change for all the specification APIs.

Switching an HTTP or AJP connector from APR/Native to NIO or NIO2 with
OpenSSL requires a change of three/four characters in one configuration
file. We have deliberately made it very easy to switch between connectors.

No-one is being forced to upgrade.


Atlassian forced me to upgrade.

This is the core of the problem - gone are the days when Tomcat was just a 
simple server that people downloaded and used to make bespoke web services and 
could write code any way they liked. Now Tomcat is part of other systems, who 
in turn have other support horizons unrelated to this project.

The AJP deprecation is a problem. For those unaware of what AJP did, AJP 
allowed a proxy server and Tomcat to be “glued” together as it they were one 
server, and not two discrete entities. The proxy configuration - that’s SSL, 
authn and authz - was passed transparently across to Tomcat which behaved as if 
Tomcat itself had performed the SSL, authn and authz. Sure, if you have a 
bespoke web service and the budget you can make hack changes to compensate. If 
your Tomcat is being provided by a vendor, or if you’re under financial strain 
due a pandemic, then no - you have a sudden very unwelcome headache.

The closest RFC compliant solution to this problem is JSON Web Tokens (JWT), 
which allows data to be passed across both securely and in an RFC compliant way 
over HTTP. Tomcat should have fixed this problem first, and then deprecated AJP 
with the clear notice “use this alternative in future”.


I don't see how JWTs relate here?

But for the sake of support, especially with the addition of UDS which 
is very very nice, it makes logically sense to split both and maybe 
leave APR only under the hood of Tomcat with a few committers supporting 
it while a recommendation would be to try on NIO(2) and have APR as a 
viable alternative? Java native support for UDS will not arrive that 
soon, especially not in 8 or 11.


WDYT?


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Objection to the deprecation of the tomcat-native/APR connector

[Michael Osipov]

Am 2020-12-06 um 11:03 schrieb Mark Thomas:

On 05/12/2020 11:38, Michael Osipov wrote:




A suitable roadmap for libtcnative would be:
* Tag current patch version
* Move to 1.3.0 and remove everything non-TLS/networking related out
* Move to 1.4.0 drop OpenSSL support for < 1.1.1 because it requires
thread locks from APR which aren't necessary with 1.1.1
* Likely split code between OpenSSL to Java and APR to Java with that we
could satisfy both sides.


There are a couple of complicating factors.

The first is that we try not to remove or change existing API users are
likely to be using in a major version. Addressing security issues is the
exception to that rule. That means that org.apache.tomcat.jni will be
supported until 9.0.x is EOL. Best guess in 6 to 7 years from now.


I agree, that would be a bad move within the same major version.


The other major factor is that Tomcat Native ships with at least one
downstream distro (Debian? or was if FreeBSD?) where only older versions
of OpenSSL are available. We'd like to be nice and not make things too
complicated for the package maintainers.


Well, isn't that really a OS vendor problem not ours? We can provide 
grace periods, but that's pretty much it. They need to solve that, not 
us on a volunteer basis. The admin/user/X can always compiled from code 
a brand new version and nothing hinders him to do so.
FreeBSD's port of libtcnative is uptodate. I provide patches on regular 
basis. Vendors like Debian or Red Hat lag years behind.



In the back of my mind I have had something along the following lines
which isn't too far from your proposal.

1. Create Tomcat Native 2.0 for Tomcat 10.1.x onwards that provides only
what is required to integrate OpenSSL with NIO and NIO2. Ideally,
without a dependency on APR. Given likely minimum JRE version
requirements of future Servlet specs, I think it will be a while before
we can take advantage of any JRE features intended to simplify native
integration.


Makes sense.


2. Continue to support Tomcat Native 1.x for Tomcat 8.5.x and 9.0.x
(10.0.x will be EOL with the first stable 10.1.x release)


Agreed, I'd be happy to for the platforms I use.


3. Once downstream distributions have access to 1.1.1 move Tomcat Native
1.2.x to 1.3.x and remove all the OpenSSL <1.1.1 code. We can make 1.3.x
recommended for Tomcat 8.5.x and 9.0.x (or even required if necessary /
appropriate).


This will take years. Won't it?


4. At the same time as 3 we probably want to review similar code for old
Windows versions, old Linux kernels etc and drop support for some of
those where appropriate too.


Looking at the APR/OpenSSL code I haven't seen anything particular 
requiring any specific OS or kernel version. That's plain POSIX 
abstracted with APR and OpenSSL internals. But yes, skimming is good.



I suspect there would be a Tomcat 1.4.x at some point to make OpenSSL 3
the minimum version.


So you would continue to support two native code trees? Wouldn't make 
even more work than today?



If we wanted to provide space for Tomcat/Native to continue providing
the level of APR support it does today, rather than Use Tomcat Native
2.x for the OpenSSL integration we could use a new name (Tomcat TLS
Native maybe?) leaving Tomcat Native free to evolve into 2.x, 3.x and
beyond.


This makes sense. Maybe a split from Tomcat Native would be a better 
alternative supporting APR only and OpenSSL only. So two libraries, not 
interrelated.


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [OT] Objection to the deprecation of the tomcat-native/APR connector

[Christopher Schultz]

Graham,

On 12/9/20 08:36, Graham Leggett wrote:

[Downstream use of Tomcat] is the core of the problem - gone are the
days when Tomcat was just a simple server that people downloaded and
used to make bespoke web services and could write code any way they
liked. Now Tomcat is part of other systems, who in turn have other
support horizons unrelated to this project.
Downstream consumers of Tomcat are welcome to re-integrate APR into 
their products if they choose to do so. If you are a paying customer and 
need a feature, it's up to your vendor (e.g. Atlassian) to either 
support you or lose your business.



The AJP deprecation is a problem. For those unaware of what AJP did,
AJP allowed a proxy server and Tomcat to be “glued” together as it
they were one server, and not two discrete entities. The proxy
configuration - that’s SSL, authn and authz - was passed
transparently across to Tomcat which behaved as if Tomcat itself had
performed the SSL, authn and authz. Sure, if you have a bespoke web
service and the budget you can make hack changes to compensate. If
your Tomcat is being provided by a vendor, or if you’re under
financial strain due a pandemic, then no - you have a sudden very
unwelcome headache.
Really, the only "hack" required is to enable the RemoteIPValve[1] and 
SSLValve[2]. I consider having to separately-compile and install mod_jk 
to be a "hack" at the web server level. httpd ships with mod_proxy 
already built-in.


I personally am very interested in deprecating and removing AJP from 
Tomcat for a number of reasons (lack of features, unnecessary additional 
complexity) but I continue to use AJP in production while I work to 
ensure that mod_proxy_* have feature parity with mod_jk (to wit, 
https://bz.apache.org/bugzilla/show_bug.cgi?id=64338, 
https://bz.apache.org/bugzilla/show_bug.cgi?id=53667, and possibly others).


If mod_proxy_http + Tomcat can't get the job done, let's actively work 
to fix those so they CAN get the job done.



The closest RFC compliant solution to this problem is JSON Web Tokens
(JWT), which allows data to be passed across both securely and in an
RFC compliant way over HTTP. Tomcat should have fixed this problem
first, and then deprecated AJP with the clear notice “use this
alternative in future”.
I'm not sure what you mean, here. While I suppose JWT can be used for 
just about anything anyone wants, it is typically used to package 
authentication and authorization information into a format that the user 
can be trusted to handle, rather than something that is maintained 
exclusively server-side (e.g. by passing that information from httpd -> 
Tomcat without involving the client).


Why would you involve the client here when you can pass anything you 
want directly to Tomcat via (RFC-compliant, I might add) HTTP headers?


(I notice that the "tomcatAuthentication"  attribute is 
AJP-only. That would be an obvious improvement to add that to either 
another Valve or incorporate into one of the existing proxy-support 
Valves in Tomcat.)


-chris

[1] 
http://tomcat.apache.org/tomcat-9.0-doc/config/valve.html#Remote_IP_Valve

[2] http://tomcat.apache.org/tomcat-9.0-doc/config/valve.html#SSL_Valve

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Objection to the deprecation of the tomcat-native/APR connector

[Mladen Turk]

On 09/12/2020 15:16, Mark Thomas wrote:

On 09/12/2020 13:36, Graham Leggett wrote:

On 01 Dec 2020, at 14:09, Mark Thomas  wrote:



Using APR to perform the low-level I/O creates additional risk without
little/no reward. Any performance benefits of using APR are offset
against the associated performance costs of transitioning the JNI boundary.



Although I spend endless hours creating tomcat-native, Mark is
on the spot here. Tomcat-native was designed back in times when
Java was unusable for serving 1K+ connections and APR was
lightweight package. Nowadays modern jdk can handle large
number of connections with acceptable performance, while APR
is expanding its third-party library dependencies which we
will ever need.

 Regards
--
^TM

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Objection to the deprecation of the tomcat-native/APR connector

[Mark Thomas]

On 09/12/2020 13:36, Graham Leggett wrote:
> On 01 Dec 2020, at 14:09, Mark Thomas  wrote:
> 
>>> I also object to the removal of OpenSSL code, for the same reason.
>>
>> It isn't being removed. The APR/Native library will be retained along
>> with OpenSSL support for the NIO and NIO2.
>>
>> I expect the scope of the APR/Native library for Tomcat 10.1.x onwards
>> will be reduced to just those native methods required to interact with
>> OpenSSL which may mean removal of the APR dependency. If we can use
>> OpenSSL without any native code of our own (e.g. via project Panama or
>> similar) then better still.
> 
> I don’t see the logic here.
> 
> If the use of native code is a risk, then I expect to see use of openssl and 
> any other API brought in by Panama avoided for the same reason?

Risk vs reward.

Using APR to perform the low-level I/O creates additional risk without
little/no reward. Any performance benefits of using APR are offset
against the associated performance costs of transitioning the JNI boundary.

For HTTP the performance difference beteeen NIO, NIO2 and APR/Native was
negligible. You could construct a test to prove any was marginally
better than the others but the differences were tiny.

The performance difference between OpenSSL and JSSE continues to be
significant. The speed at which new features are available is also a
factor. Java 8 has only just got TLS 1.3 support. Post handshake
authentication is, as far as I am aware, still unsupported. The
situation with ALPN was similar.

Using native code is not without risks but the risks are smaller if we
just wrap OpenSSL because the scope of the native code is narrower. For
HTTPS, NIO/NIO2+OpenSSL offers similar performance to APR/Native+OpenSSL
at a lower risk.

For users for whom the risk of using Native code is acceptable,
NIO/NIO2+OpenSSL offers the same benefits at lower risk compared to
APR/Native+OpenSSL.


>>> We are in the middle of a global pandemic. Our users do not have the 
>>> resources to suddenly divert to reengineering what is to them a perfectly 
>>> working system, to replace what exists with something else that just works 
>>> differently.
>>
>> Upgrading to Tomcat 10 already requires significant re-engineering work
>> due to the java package change for all the specification APIs.
>>
>> Switching an HTTP or AJP connector from APR/Native to NIO or NIO2 with
>> OpenSSL requires a change of three/four characters in one configuration
>> file. We have deliberately made it very easy to switch between connectors.
>>
>> No-one is being forced to upgrade.
> 
> Atlassian forced me to upgrade.

Then complain to Atlassian. I'd be very interested to understand
Atlassian's reasoning if they are prepared to share it.

> This is the core of the problem - gone are the days when Tomcat was just a 
> simple server that people downloaded and used to make bespoke web services 
> and could write code any way they liked. Now Tomcat is part of other systems, 
> who in turn have other support horizons unrelated to this project.
> 
> The AJP deprecation is a problem. For those unaware of what AJP did, AJP 
> allowed a proxy server and Tomcat to be “glued” together as it they were one 
> server, and not two discrete entities. The proxy configuration - that’s SSL, 
> authn and authz - was passed transparently across to Tomcat which behaved as 
> if Tomcat itself had performed the SSL, authn and authz. Sure, if you have a 
> bespoke web service and the budget you can make hack changes to compensate. 
> If your Tomcat is being provided by a vendor, or if you’re under financial 
> strain due a pandemic, then no - you have a sudden very unwelcome headache.
> 
> The closest RFC compliant solution to this problem is JSON Web Tokens (JWT), 
> which allows data to be passed across both securely and in an RFC compliant 
> way over HTTP. Tomcat should have fixed this problem first, and then 
> deprecated AJP with the clear notice “use this alternative in future”.

AJP is not deprecated. Tomcat has not deprecated support for AJP nor
announced plans to deprecate support for AJP. Tomcat has not made
feature parity with AJP a priority for the AJP alternatives because
there are no plans to deprecate AJP.

Deprecation of AJP was discussed back in 2018 but no decision was made.
Reviewing those discussions the primary motivation for deprecation
seemed to by the argument that AJP did not (and was not likely to)
provide support for features like WebSocket and encryption.

I can see the arguments for deprecating AJP now as I did then but the
size of the user base and the lack of feature parity with the mod_jk
alternatives for IIS (at least the last time I looked) means I think it
is unlikely AJP will be deprecated any time soon.

Even when we had the recent security issue with AJP (CVE-2020-1938) none
of our communication around that issue indicated that AJP was even being
considered for deprecation nor did it suggest users switched to a
different protocol.

Mark

Re: Objection to the deprecation of the tomcat-native/APR connector

[Graham Leggett]

On 01 Dec 2020, at 14:09, Mark Thomas  wrote:

>> I also object to the removal of OpenSSL code, for the same reason.
> 
> It isn't being removed. The APR/Native library will be retained along
> with OpenSSL support for the NIO and NIO2.
> 
> I expect the scope of the APR/Native library for Tomcat 10.1.x onwards
> will be reduced to just those native methods required to interact with
> OpenSSL which may mean removal of the APR dependency. If we can use
> OpenSSL without any native code of our own (e.g. via project Panama or
> similar) then better still.

I don’t see the logic here.

If the use of native code is a risk, then I expect to see use of openssl and 
any other API brought in by Panama avoided for the same reason?

>> We are in the middle of a global pandemic. Our users do not have the 
>> resources to suddenly divert to reengineering what is to them a perfectly 
>> working system, to replace what exists with something else that just works 
>> differently.
> 
> Upgrading to Tomcat 10 already requires significant re-engineering work
> due to the java package change for all the specification APIs.
> 
> Switching an HTTP or AJP connector from APR/Native to NIO or NIO2 with
> OpenSSL requires a change of three/four characters in one configuration
> file. We have deliberately made it very easy to switch between connectors.
> 
> No-one is being forced to upgrade.

Atlassian forced me to upgrade.

This is the core of the problem - gone are the days when Tomcat was just a 
simple server that people downloaded and used to make bespoke web services and 
could write code any way they liked. Now Tomcat is part of other systems, who 
in turn have other support horizons unrelated to this project.

The AJP deprecation is a problem. For those unaware of what AJP did, AJP 
allowed a proxy server and Tomcat to be “glued” together as it they were one 
server, and not two discrete entities. The proxy configuration - that’s SSL, 
authn and authz - was passed transparently across to Tomcat which behaved as if 
Tomcat itself had performed the SSL, authn and authz. Sure, if you have a 
bespoke web service and the budget you can make hack changes to compensate. If 
your Tomcat is being provided by a vendor, or if you’re under financial strain 
due a pandemic, then no - you have a sudden very unwelcome headache.

The closest RFC compliant solution to this problem is JSON Web Tokens (JWT), 
which allows data to be passed across both securely and in an RFC compliant way 
over HTTP. Tomcat should have fixed this problem first, and then deprecated AJP 
with the clear notice “use this alternative in future”.

Regards,
Graham
—

Re: Objection to the deprecation of the tomcat-native/APR connector

[Emmanuel Bourg]

Le 06/12/2020 à 11:03, Mark Thomas a écrit :

> 3. Once downstream distributions have access to 1.1.1 move Tomcat Native
> 1.2.x to 1.3.x and remove all the OpenSSL <1.1.1 code. We can make 1.3.x
> recommended for Tomcat 8.5.x and 9.0.x (or even required if necessary /
> appropriate).

The current state of OpenSSL in Debian is:
- OpenSSL 1.0.1t in Debian 8 (no longer supported)
- OpenSSL 1.1.0l in Debian 9 (EOL in June 2022)
- OpenSSL 1.1.1d in Debian 10

And in Ubuntu:
- OpenSSL 1.0.2g in Ubuntu 16.04 LTS (EOL in April 2021)
- OpenSSL 1.1.1  in Ubuntu 18.04 LTS
- OpenSSL 1.1.1f in Ubuntu 20.04 LTS

Emmanuel Bourg

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Objection to the deprecation of the tomcat-native/APR connector

[Mark Thomas]

On 05/12/2020 11:38, Michael Osipov wrote:



> A suitable roadmap for libtcnative would be:
> * Tag current patch version
> * Move to 1.3.0 and remove everything non-TLS/networking related out
> * Move to 1.4.0 drop OpenSSL support for < 1.1.1 because it requires
> thread locks from APR which aren't necessary with 1.1.1
> * Likely split code between OpenSSL to Java and APR to Java with that we
> could satisfy both sides.

There are a couple of complicating factors.

The first is that we try not to remove or change existing API users are
likely to be using in a major version. Addressing security issues is the
exception to that rule. That means that org.apache.tomcat.jni will be
supported until 9.0.x is EOL. Best guess in 6 to 7 years from now.

Related to that, if we remove things bit by bit it takes a very long
time as we can only remove in a new major version which happens
(roughly) every three years.

The other major factor is that Tomcat Native ships with at least one
downstream distro (Debian? or was if FreeBSD?) where only older versions
of OpenSSL are available. We'd like to be nice and not make things too
complicated for the package maintainers.

In the back of my mind I have had something along the following lines
which isn't too far from your proposal.

1. Create Tomcat Native 2.0 for Tomcat 10.1.x onwards that provides only
what is required to integrate OpenSSL with NIO and NIO2. Ideally,
without a dependency on APR. Given likely minimum JRE version
requirements of future Servlet specs, I think it will be a while before
we can take advantage of any JRE features intended to simplify native
integration.

2. Continue to support Tomcat Native 1.x for Tomcat 8.5.x and 9.0.x
(10.0.x will be EOL with the first stable 10.1.x release)

3. Once downstream distributions have access to 1.1.1 move Tomcat Native
1.2.x to 1.3.x and remove all the OpenSSL <1.1.1 code. We can make 1.3.x
recommended for Tomcat 8.5.x and 9.0.x (or even required if necessary /
appropriate).

4. At the same time as 3 we probably want to review similar code for old
Windows versions, old Linux kernels etc and drop support for some of
those where appropriate too.

I suspect there would be a Tomcat 1.4.x at some point to make OpenSSL 3
the minimum version.

If we wanted to provide space for Tomcat/Native to continue providing
the level of APR support it does today, rather than Use Tomcat Native
2.x for the OpenSSL integration we could use a new name (Tomcat TLS
Native maybe?) leaving Tomcat Native free to evolve into 2.x, 3.x and
beyond.

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Objection to the deprecation of the tomcat-native/APR connector

[Michael Osipov]

Am 2020-12-01 um 13:09 schrieb Mark Thomas:

On 01/12/2020 11:05, Graham Leggett wrote:

Hi all,

I object to the deprecation of the tomcat-native/APR connector.

Most specifically, I am -1 on the following:

https://marc.info/?l=tomcat-dev=160681846808019=2

Looking at past discussion on this, the justification has been:

"It is inherently less stable. If we get the NIO code wrong, you might
see a NullPointerException. If we get the APR code wrong you might see a
JVM crash.”

Both a NullPointerException and a crash result in the same outcome - a non 
working server.


No it isn't. The difference is a single failed request compared to the
entire server failing.


Tomcat-native has releases in the 
https://archive.apache.org/dist/tomcat/tomcat-connectors/native/ going back 15 
years to 2005, a claim of a lack of stability needs to be quantifiable.


See the long list of bugs raised against Tomcat and the Tomcat Native
Connector that reported a JVM crash. The reports have slowly been
getting less frequent over the years and are at a much lower level now
than they were but the risk remains.


I also object to the removal of OpenSSL code, for the same reason.


It isn't being removed. The APR/Native library will be retained along
with OpenSSL support for the NIO and NIO2.

I expect the scope of the APR/Native library for Tomcat 10.1.x onwards
will be reduced to just those native methods required to interact with
OpenSSL which may mean removal of the APR dependency. If we can use
OpenSSL without any native code of our own (e.g. via project Panama or
similar) then better still.


We are in the middle of a global pandemic. Our users do not have the resources 
to suddenly divert to reengineering what is to them a perfectly working system, 
to replace what exists with something else that just works differently.


Upgrading to Tomcat 10 already requires significant re-engineering work
due to the java package change for all the specification APIs.

Switching an HTTP or AJP connector from APR/Native to NIO or NIO2 with
OpenSSL requires a change of three/four characters in one configuration
file. We have deliberately made it very easy to switch between connectors.

No-one is being forced to upgrade. Tomcat 8.5.x and 9.0.x will continue
to support the APR/Native connector for AJP and HTTP. Based on the
typical 10 year support lifetime of a major Tomcat release users have at
least five to six years before they would be forced to migrate away from
using an APR/Native HTTP or AJP connector.

I'll note that Tomcat supports at least 3 major versions in parallel
with each major version being supported for ~10 years. That is a very
generous support offering.


Mark, while I always appreciate your professional answers, I do agree 
with Graham from a different opinion:
As most of you have noticed I worked to some extend on libtcnative 
because it simply works for me and just has failed only once many many 
years go. I tried to remove some light APR dependencies for many OSes. 
Now, we all know pre-10 Tomcat versions won't go away soon we will 
continue support libtcnative for those versions anyway.
With or without the deprecation, we can always say if APR does not work 
for you, take NIO2.

A suitable roadmap for libtcnative would be:
* Tag current patch version
* Move to 1.3.0 and remove everything non-TLS/networking related out
* Move to 1.4.0 drop OpenSSL support for < 1.1.1 because it requires 
thread locks from APR which aren't necessary with 1.1.1
* Likely split code between OpenSSL to Java and APR to Java with that we 
could satisfy both sides.


I am now nicely acquiant with the code, I could at least remove 
everything for 1.3.0 and have at least three completely different OSes 
to test.


Another side note is that building on Windows is a pain, I do not and 
will not install Visual Studio to compile a few hundred lines of C code. 
I would highly favorize a CMake-based build which works on Windows too, 
but that is a different discussion, of course.


Michael


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Objection to the deprecation of the tomcat-native/APR connector

[Mladen Turk]

On 01/12/2020 12:05, Graham Leggett wrote:

Hi all,

I object to the deprecation of the tomcat-native/APR connector.



Understand, but APR is the major problem. Tomcat Native uses
a small subset of APR (networking), and since APR will
eventually merge with apr-util (already merged in apr/trunk)
this is going to be a problem.

There are already exiting forks of tomcat-native without
using APR (with rewritten networking part), and this
solves 99% crashes, since there are no apr_pools API involved
which are incompatible with Java's Garbage Collection model.

So .. we can either refactor tomcat-native by dropping APR
and create our own network stack while preserving the API
or deprecate the entire thing.


Regards
--
^TM

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Objection to the deprecation of the tomcat-native/APR connector

[Christopher Schultz]

Graham,

On 12/1/20 12:43, Graham Leggett wrote:

On 01 Dec 2020, at 13:48, Rémy Maucherat  wrote:


You still have years to plan a migration off the APR connector as it will
only be removed in 10.1 and Tomcat 9.0 continues to be supported.

This eventual removal or APR has been discussed for years. BTW, so that you
know, there are also discussions about AJP.


I am painfully aware of the discussions on the removal of AJP.

I first encountered this problem when Atlassian arbitrarily announced
removal of support for AJP (I assume off the back of the discussion),
leaving no practical way to pass certificates across to Tomcat.

   RequestHeader Client-Certificate %{SSL_CLIENT_CERT}

Does that not work? Or does it require this:


For this reason I developed the RFC compliant secure base64url API here:

https://github.com/apache/apr/blob/trunk/include/apr_encode.h 



?


Organised the donation of and then brought the RFC compliant JSON API up to the 
required security level here:

https://github.com/apache/apr/blob/trunk/include/apr_json.h 


Added digest support to the crypto API here:

https://github.com/apache/apr-util/blob/1.7.x/include/apr_crypto.h 


Add an RFC compliant JOSE implementation here:

https://github.com/apache/apr-util/blob/1.7.x/include/apr_jose.h 


Then added the two modules mod_auth_bearer and mod_autht_jwt here (outstanding 
for want of docs):

http://apache-http-server.18135.x6.nabble.com/Patch-mod-auth-bearer-mod-autht-jwt-An-alternative-to-AJP-td5051929.html#a5051936
 


Then created the option for Tomcat to read info from JWT here:

https://github.com/minfrin/tomcat7-jwt-authenticator 



Your arm must really hurt from patting yourself on the back so hard.

Why not fix mod_proxy_http so it can "practically" send X.509 
certificates (or chains) to a Tomcat back-end. you experience with 
httpd, mod_proxy, and TLS ought to make it pretty easy to do that.



While it can be tempting to downplay the arbitrary removal of
capabilities from tomcat as “a few characters” change, or by telling
people they  have “years” to make a change, the knock-on effect of these
changes are significant and very expensive.


Yes, and the knock-on effects of continuing to support the APR connector 
are a pain in our collective behinds. Feel free to step-up and fix all 
the bugs in tcnative.



I would appreciate the help minimising the impact of these changes
before I encounter them unexpectedly in an update from a vendor.


It's not an update. It's a new release. It's practically a different 
product. Had we dropped APR and AJP in 7.0.107 or something like that, I 
would understand your argument. But we are talking about a major release.


Did you notice that we killed BIO? That was a much bigger deal than 
dropping APR.


-chris

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Objection to the deprecation of the tomcat-native/APR connector

[Christopher Schultz]

Graham,

On 12/1/20 06:05, Graham Leggett wrote:

Hi all,

I object to the deprecation of the tomcat-native/APR connector.

Most specifically, I am -1 on the following:

https://marc.info/?l=tomcat-dev=160681846808019=2

Looking at past discussion on this, the justification has been:

"It is inherently less stable. If we get the NIO code wrong, you might
see a NullPointerException. If we get the APR code wrong you might see a
JVM crash.”

Both a NullPointerException and a crash result in the same outcome -
a non working server.
I agree with Mark's response to this, and I will add that native crashes 
can have a nasty habit of turning into security vulnerabilities.


If you have 0.001% of requests failing in NIO, you have a "working 
server". If you hit a single one of those with the APR connector, you 
are suddenly 100% down.



Tomcat-native has releases in the
https://archive.apache.org/dist/tomcat/tomcat-connectors/native/
going back > 15 years to 2005, a claim of a lack of stability needs
to be quantifiable.
It's hard to get metrics on how many native crashes are being suffered, 
as Tomcat doesn't send telemetry back to the ASF. There are a bunch of 
open, unexplained native crash reports in Bugzilla filed against 
tcnative around the parts used by the APR connector. We have tried to 
make the code as safe as possible, but some things are still falling 
through the cracks.


It's easy from first-principles to decide that less native code is a net 
win for Tomcat and its users.



I also object to the removal of OpenSSL code, for the same reason.


We aren't removing that.


We are in the middle of a global pandemic. Our users do not have the
resources to suddenly divert to reengineering what is to them a
perfectly working system, to replace what exists with something else
that just works differently.


Tomcat 10 hasn't even been released as a stable product, yet. The oldest 
currently-supported version of Tomcat is Tomcat 7 which has been 
supported since its first stable release on 2011-01-14. That's nearly 10 
years of support. We are past the 10-year mark already if you include 
the pre-stable period of time starting 2010-06-29.


Exactly how long do you need to plan and execute a migration away from 
the APR connector?


I think we're all happy to accept feedback of the form "please don't 
remove this feature", but "timing" really isn't a good argument against 
this change.


-chris

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Objection to the deprecation of the tomcat-native/APR connector

[Martin Grigorov]

Hi Graham,

On Tue, Dec 1, 2020 at 7:43 PM Graham Leggett 
wrote:

> On 01 Dec 2020, at 13:48, Rémy Maucherat  wrote:
>
> > You still have years to plan a migration off the APR connector as it will
> > only be removed in 10.1 and Tomcat 9.0 continues to be supported.
> >
> > This eventual removal or APR has been discussed for years. BTW, so that
> you
> > know, there are also discussions about AJP.
>
> I am painfully aware of the discussions on the removal of AJP.
>
> I first encountered this problem when Atlassian arbitrarily announced
> removal of support for AJP (I assume off the back of the discussion),
> leaving no practical way to pass certificates across to Tomcat.
>
> For this reason I developed the RFC compliant secure base64url API here:
>
> https://github.com/apache/apr/blob/trunk/include/apr_encode.h <
> https://github.com/apache/apr/blob/trunk/include/apr_encode.h>
>
> Organised the donation of and then brought the RFC compliant JSON API up
> to the required security level here:
>
> https://github.com/apache/apr/blob/trunk/include/apr_json.h <
> https://github.com/apache/apr/blob/trunk/include/apr_json.h>
>
> Added digest support to the crypto API here:
>
> https://github.com/apache/apr-util/blob/1.7.x/include/apr_crypto.h <
> https://github.com/apache/apr-util/blob/1.7.x/include/apr_crypto.h>
>
> Add an RFC compliant JOSE implementation here:
>
> https://github.com/apache/apr-util/blob/1.7.x/include/apr_jose.h <
> https://github.com/apache/apr-util/blob/1.7.x/include/apr_jose.h>
>
> Then added the two modules mod_auth_bearer and mod_autht_jwt here
> (outstanding for want of docs):
>
>
> http://apache-http-server.18135.x6.nabble.com/Patch-mod-auth-bearer-mod-autht-jwt-An-alternative-to-AJP-td5051929.html#a5051936
> <
> http://apache-http-server.18135.x6.nabble.com/Patch-mod-auth-bearer-mod-autht-jwt-An-alternative-to-AJP-td5051929.html#a5051936
> >
>
> Then created the option for Tomcat to read info from JWT here:
>
> https://github.com/minfrin/tomcat7-jwt-authenticator <
> https://github.com/minfrin/tomcat7-jwt-authenticator>
>
> While it can be tempting to downplay the arbitrary removal of capabilities
> from tomcat as “a few characters” change, or by telling people they  have
> “years” to make a change, the knock-on effect of these changes are
> significant and very expensive.
>
> I would appreciate the help minimising the impact of these changes before
> I encounter them unexpectedly in an update from a vendor.
>

As I suggested in your PR about Unix Domain Sockets support - what about
extracting the APR (and AJP ?!) code into its own project!
The main work has been done over the years. Now it just needs someone to
maintain it.

Regards,
Martin


>
> Regards,
> Graham
> —
>
>

Re: Objection to the deprecation of the tomcat-native/APR connector

[Graham Leggett]

On 01 Dec 2020, at 13:48, Rémy Maucherat  wrote:

> You still have years to plan a migration off the APR connector as it will
> only be removed in 10.1 and Tomcat 9.0 continues to be supported.
> 
> This eventual removal or APR has been discussed for years. BTW, so that you
> know, there are also discussions about AJP.

I am painfully aware of the discussions on the removal of AJP.

I first encountered this problem when Atlassian arbitrarily announced removal 
of support for AJP (I assume off the back of the discussion), leaving no 
practical way to pass certificates across to Tomcat.

For this reason I developed the RFC compliant secure base64url API here:

https://github.com/apache/apr/blob/trunk/include/apr_encode.h 


Organised the donation of and then brought the RFC compliant JSON API up to the 
required security level here:

https://github.com/apache/apr/blob/trunk/include/apr_json.h 


Added digest support to the crypto API here:

https://github.com/apache/apr-util/blob/1.7.x/include/apr_crypto.h 


Add an RFC compliant JOSE implementation here:

https://github.com/apache/apr-util/blob/1.7.x/include/apr_jose.h 


Then added the two modules mod_auth_bearer and mod_autht_jwt here (outstanding 
for want of docs):

http://apache-http-server.18135.x6.nabble.com/Patch-mod-auth-bearer-mod-autht-jwt-An-alternative-to-AJP-td5051929.html#a5051936
 


Then created the option for Tomcat to read info from JWT here:

https://github.com/minfrin/tomcat7-jwt-authenticator 


While it can be tempting to downplay the arbitrary removal of capabilities from 
tomcat as “a few characters” change, or by telling people they  have “years” to 
make a change, the knock-on effect of these changes are significant and very 
expensive.

I would appreciate the help minimising the impact of these changes before I 
encounter them unexpectedly in an update from a vendor.

Regards,
Graham
—

Re: Objection to the deprecation of the tomcat-native/APR connector

[Mark Thomas]

On 01/12/2020 11:05, Graham Leggett wrote:
> Hi all,
> 
> I object to the deprecation of the tomcat-native/APR connector.
> 
> Most specifically, I am -1 on the following:
> 
> https://marc.info/?l=tomcat-dev=160681846808019=2
> 
> Looking at past discussion on this, the justification has been:
> 
> "It is inherently less stable. If we get the NIO code wrong, you might
> see a NullPointerException. If we get the APR code wrong you might see a
> JVM crash.”
> 
> Both a NullPointerException and a crash result in the same outcome - a non 
> working server.

No it isn't. The difference is a single failed request compared to the
entire server failing.

> Tomcat-native has releases in the 
> https://archive.apache.org/dist/tomcat/tomcat-connectors/native/ going back 
> 15 years to 2005, a claim of a lack of stability needs to be quantifiable.

See the long list of bugs raised against Tomcat and the Tomcat Native
Connector that reported a JVM crash. The reports have slowly been
getting less frequent over the years and are at a much lower level now
than they were but the risk remains.

> I also object to the removal of OpenSSL code, for the same reason.

It isn't being removed. The APR/Native library will be retained along
with OpenSSL support for the NIO and NIO2.

I expect the scope of the APR/Native library for Tomcat 10.1.x onwards
will be reduced to just those native methods required to interact with
OpenSSL which may mean removal of the APR dependency. If we can use
OpenSSL without any native code of our own (e.g. via project Panama or
similar) then better still.

> We are in the middle of a global pandemic. Our users do not have the 
> resources to suddenly divert to reengineering what is to them a perfectly 
> working system, to replace what exists with something else that just works 
> differently.

Upgrading to Tomcat 10 already requires significant re-engineering work
due to the java package change for all the specification APIs.

Switching an HTTP or AJP connector from APR/Native to NIO or NIO2 with
OpenSSL requires a change of three/four characters in one configuration
file. We have deliberately made it very easy to switch between connectors.

No-one is being forced to upgrade. Tomcat 8.5.x and 9.0.x will continue
to support the APR/Native connector for AJP and HTTP. Based on the
typical 10 year support lifetime of a major Tomcat release users have at
least five to six years before they would be forced to migrate away from
using an APR/Native HTTP or AJP connector.

I'll note that Tomcat supports at least 3 major versions in parallel
with each major version being supported for ~10 years. That is a very
generous support offering.

Regards,

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Objection to the deprecation of the tomcat-native/APR connector

[Rémy Maucherat]

On Tue, Dec 1, 2020 at 12:05 PM Graham Leggett 
wrote:

> Hi all,
>
> I object to the deprecation of the tomcat-native/APR connector.
>
> Most specifically, I am -1 on the following:
>
> https://marc.info/?l=tomcat-dev=160681846808019=2
>
> Looking at past discussion on this, the justification has been:
>
> "It is inherently less stable. If we get the NIO code wrong, you might
> see a NullPointerException. If we get the APR code wrong you might see a
> JVM crash.”
>
> Both a NullPointerException and a crash result in the same outcome - a non
> working server. Tomcat-native has releases in the
> https://archive.apache.org/dist/tomcat/tomcat-connectors/native/ going
> back 15 years to 2005, a claim of a lack of stability needs to be
> quantifiable.
>
> I also object to the removal of OpenSSL code, for the same reason.
>
> We are in the middle of a global pandemic. Our users do not have the
> resources to suddenly divert to reengineering what is to them a perfectly
> working system, to replace what exists with something else that just works
> differently.
>

You still have years to plan a migration off the APR connector as it will
only be removed in 10.1 and Tomcat 9.0 continues to be supported.

This eventual removal or APR has been discussed for years. BTW, so that you
know, there are also discussions about AJP. However, the OpenSSL support as
used by NIO/NIO2 is not under consideration for removal. Its wrapper could
however be replaced by using some Java code rather than C code (Panama).

Yes, there's an overall plan to remove our native code ...

Rémy


> Regards,
> Graham
> —
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Objection to the deprecation of the tomcat-native/APR connector

[Graham Leggett]

Hi all,

I object to the deprecation of the tomcat-native/APR connector.

Most specifically, I am -1 on the following:

https://marc.info/?l=tomcat-dev=160681846808019=2

Looking at past discussion on this, the justification has been:

"It is inherently less stable. If we get the NIO code wrong, you might
see a NullPointerException. If we get the APR code wrong you might see a
JVM crash.”

Both a NullPointerException and a crash result in the same outcome - a non 
working server. Tomcat-native has releases in the 
https://archive.apache.org/dist/tomcat/tomcat-connectors/native/ going back 15 
years to 2005, a claim of a lack of stability needs to be quantifiable.

I also object to the removal of OpenSSL code, for the same reason.

We are in the middle of a global pandemic. Our users do not have the resources 
to suddenly divert to reengineering what is to them a perfectly working system, 
to replace what exists with something else that just works differently.

Regards,
Graham
—


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org