Just to update, we were able to work around this by changing our server.xml
connector config from:
protocol="HTTP/1.1"
to:
protocol="org.apache.coyote.http11.Http11Nio2Protocol"
sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEImplementation"
Somewhere deep within Http11NioProtocol there is a bug that is fixed in
Http11Nio2Protocol. Unfortunately, we don’t have the bandwidth to try to
isolate it further, though I will update if anything else is uncovered.
Thanks,
Peter
On 7/20/16, 11:13 AM, "Peter Robbins" <peter.robb...@jamfsoftware.com> wrote:
That’s good to know. In the short term I think we’re going to revert back to
the 8.0.x branch and see if we can find put together a more isolated repro war
to try to nail this thing down. Thanks for your help!
Peter
On 7/20/16, 7:40 AM, "Rémy Maucherat" <r...@apache.org> wrote:
2016-07-20 13:59 GMT+02:00 Peter Robbins <peter.robb...@jamfsoftware.com>:
> Ok I'll see if I can dig BC out of the application and have it actually
> start up to try to see if that's the case.
>
> You're saying there are known compatibility issues with Tomcat NIO https
> if you register another j2ee security provider?
No, but we're not testing that kind of configuration at all. Since there's
OpenSSL support, it seems less important now as well.
> The errors we're seeing don't seem crypto related apart from only
> appearing over https.
>
Rémy
