tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: svn commit: r1833172 - /tomcat/trunk/TOMCAT-NEXT.txt
Date Fri, 08 Jun 2018 15:38:27 GMT
On 08/06/18 15:40, Rémy Maucherat wrote:
> On Fri, Jun 8, 2018 at 4:10 PM <> wrote:
>> +1.  Remove the use of system properties to control configuration wherever
>> +    possible.
> Ok. My bad, I'm a recovering addict ... ;)


>> +2.  Reduce instances of setters and getters for the same property
>> existing on an
>> +    object and its parent. This may require new objects to be exposed via
>> JMX.
> Ok. I'm not sure where though, just like that.

I think a lot of this will go away when the deprecated Connector code is
removed. Beyond that there are bits an pieces of duplication. I think of
this entry more as something to look at if there is some spare time at a
point where we can still change the API.

>> +3.  Consider wrapping the SocketWrapper with a facade to detect / prevent
>> +    components retaining references longer than they should.
> On the plus side, the components are privileged, so if something goes wrong
> it's the component's fault and not a security issue. It depends on how much
> use this gets ultimately. I suppose quite a bit moving forward, so there
> should be an option there. It's obviously going to be cheap too.

Agreed. This is more of a protect the apps from themselves feature.

>> +New items for 10.0.x onwards:
>> +1.  Remove APR connector.
>> +2.  Remove org.apache.tomcat.jni and replace with the minimum necessary to
>> +    interface with OpenSSL and clones.
> Yes, but I still have no answer for the assertion that APR is still the
> fastest connector. So this performance drop has to be accepted. On the plus
> side, I would say APR users are not a majority, so this could go well.
> Functionally, APR is now more a problem than a solution in Tomcat
> ("sendfile" done differently works well now).

I thought the most recent round of testing showed that the difference
was marginal for "NIO HTTP" vs "APR HTTP" and "NIO+OpenSSL" vs "NIO APR

If that isn't the case then there is much less of a case for removing APR.

> Ideas:
> - Someone mentioned a new compiler API could be used in Jasper
> - An embedded 2 API ?
> - Whatever from the early work of the EE EG (reactive shiny thingies ?)

All sound good.


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

View raw message