2017-06-12 17:07 GMT-05:00 Mark Thomas <ma...@apache.org>: > 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? > > Are you sure it's not simply still this bug: https://bz.apache.org/bugzilla/show_bug.cgi?id=60461 ? I agree the fix is "hard" since, although there's no actual async close (I don't see any completion handler closing things abruptly personally - on read I failed to do anything async for now, and on write the completion handler simply sets an error field to be processed synchronously later), closing can occur after parsing any frame. IMO with HTTP/2 everything is async to the application, so it's the same for all connectors.
Rémy
