On 08/06/18 15:40, Rémy Maucherat wrote:
> On Fri, Jun 8, 2018 at 4:10 PM <ma...@apache.org> wrote:
>
>> +1. Remove the use of system properties to control configuration wherever
>> + possible.
>>
>
> Ok. My bad, I'm a recovering addict ... ;)
Grin.
>> +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
HTTPS".
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.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
