Created attachment 34866 [details] server.xml configure file Environment: OS: Red Hat Enterprise Linux Server release 6.7 2.6.32-573.el6.x86_64 JDK: version "1.8.0_65" Java HotSpot(TM) 64-Bit Server VM Memory: 16G CPU: 1 Tomcat: tested 8.5.3 and 8.5.11 APR: 1.5.2-1 Test step: 1. Install tomcat 2. Test home page ./wrk -t2000 -c 2000 -d 100s http://testhost:8080/ Exception throws in catalina.log: 22-Mar-2017 09:09:04.344 WARNING [http-apr-8080-Poller] org.apache.tomcat.util.net.AprEndpoint$Poller.run Unexpected poller error java.lang.NullPointerException at org.apache.tomcat.util.net.AprEndpoint$AprSocketWrapper.access$400(AprEndpoint.java:2292) at org.apache.tomcat.util.net.AprEndpoint$Poller.run(AprEndpoint.java:1703) at java.lang.Thread.run(Thread.java:745)
The similar bug https://bz.apache.org/bugzilla/show_bug.cgi?id=54513
Any update? Server closed connection and Client will receive RST due to this issue.
I have been unable to reproduce this with 9.0.x or 8.5.x. Next step is a code review to try and identify a code path that could trigger this. I don't want to just ignore the null without understanding what is going on.
One additional question. Which version of Tomcat Native are you using?
I was looking at possible triggers for this around concurrent timeout/close and new data arriving. While I was doing that I found and fixed some edge cases that made this bug easier to trigger. I have therefore fixed this bug too. Fixed in: - trunk for 9.0.0.M19 onwards - 8.5.x for 8.5.13 onwards
Tomcat 8.5.3, Tomcat Native 1.2.7 TOmcat 8.5.11 Tomcat Native 1.2.10 Thanks Mark, I will test fixed version when it is available.
The fix for Bug 60900 (https://bz.apache.org/bugzilla/show_bug.cgi?id=60900) should also be applied to Tomcat 7.0.x. The issue still exists in 7.0.81, as the wrapper assigned on AprEndpoint.java:1898 is not checked for null prior to reference on AprEndpoint.java:1906.
I've back-ported the NPE fix to: - 8.0.x for 8.0.47 onwards - 7.0.x for 7.0.82 onwards I didn't back-port the edge case fixes as the refactoring in 8.5.x means the associated code is different (e.g. it has Comet handling) and I didn't want to risk triggering a regression.