On 09/06/17 16:02, Kreuser, Peter wrote: > Hi all, > > Sorry for the long text. I hope somebody can help me track down the problem > I'm facing with Tomcat (8.5.15), tcnative (1.2.12), openssl (1.1.0e) and > HTTP/2. JVM is zulu-8.21.0.1 (1.8.0_131-b11)
No need to apologise. There was enough information in this report for me to be 95% sure of what was going on before I tested things locally. <snip/> > Would be nice if somebody here could tell me if that is a bug or if I have > some misconfiguration. It is a bug. The short explanation is that with NIO2, the style of the API (async read/write with CompletionHandlers) means that a TLS connection can get closed down (by a CompletionHandler) before the access log entry is written. This leads to passing a NULL reference to some native code which - unsurprisingly - falls over (Tomcat is meant to make sure it doesn't pass NULL references). There is an easy fix but the side-effect is that sometimes the cipher suite name won't appear in the access log. Depending on timing on your system that could be very frequent to almost never. I'd roughly expect it to happen as frequently as the crashes. The harder fix is to note that we want the info and to ensure we cache it before the TLS connection is closed down. In theory, we could do this in the access log but it means parsing the request attribute config. Performance wise, there will be an impact on users since the lookup to populate the cache will occur during request processing rather than afterwards. However, overall throughput should be unaffected. An alternative fix is for the application to trigger the caching of the TLS info by requesting one of the TLD attributes. Switching to NIO should also fix this. Note, I would not expect NIO and NIO2 to be much different performance wise. Would the easy fix be sufficient? Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
