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 <r...@apache.org> 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 <micha...@apache.org> > > 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 > > > > > > > > >
