Created attachment 31535 [details] Crash error log Hi, Recently, we encountered Tomcat crash on EXCEPTION_ACCESS_VIOLATION. I attached error log. We've seen this issue few times and it always seems to be related to "JavaThread "http-apr-80-Poller" daemon". To be honest, I don't know how to simulate this. It happens quite randomly. Due to # Problematic frame: # C [tcnative-1.dll+0x6db6] and =>0x3b9a3400 JavaThread "http-apr-80-Poller" daemon [_thread_in_native, id=912, stack(0x3fd20000,0x3fd90000)] I assume that this is Tomcat error. We use Tomcat to run our own simple web app and Infinispan REST server.
Is use of tcnative important for you? You could switch to the NIO connector which won't crash your JVM. It appears that you are on Windows, yes? What version of tcnative are you using? Tomcat 7.0.47 ships with 1.1.29. tcnative 1.1.30 is newly available and not vulnerable to Heartbleed as well. Could you test with 1.1.30?
(In reply to Christopher Schultz from comment #1) > Is use of tcnative important for you? You could switch to the NIO connector > which won't crash your JVM. > > It appears that you are on Windows, yes? What version of tcnative are you > using? Tomcat 7.0.47 ships with 1.1.29. tcnative 1.1.30 is newly available > and not vulnerable to Heartbleed as well. Could you test with 1.1.30? We are running on Windows Server 2008 R2 Standard. We really don't case whether we use tcnative or NIO Connector. Important thing is that it's working. Does usage of NIO Connector over tcnative have any noticable performance hit that we should be aware of? We put quite a load on Infinispan REST server deployed inside Tomcat. We are using tcnative which ships in default Tomcat 7.0.47 package. We didn't changed/upgraded any Tomcat dependency. Therefore, we use Tomcat tcnative 1.1.29.
Can you please advise how we can change to NIO Connectors?
There are two performance-related items of note when switching from APR to NIO. The first is with SSL. If you are having Tomcat terminate SSL, you will see a noticeable drop in performance when compared to OpenSSL (which APR uses). Something like a 25% drop wouldn't surprise me. It will depend upon your load profile. The second is that you will notice CPU usage on the server increase a bit over use of APR. You may notice CPU usage triple or quadruple when compared to running APR without any other load on the server. PLEASE NOTE THAT I'M COMPARING ONLY THE OVERHEAD OF TOMCAT'S CONNECTORS, HERE. That means that if your server is running at 60% CPU load most of the time, I'm not claiming that you'll suddenly need 240% of your CPU in order to keep up. Remember that Tomcat's connector only uses a tiny slice of the CPU compared to whatever your own web application is doing. To switch to the NIO connector, please read Tomcat's user guide. There is a section on Connectors which for some reason does not link to the Connectors section in the "Configuration" guide. The configuration guide is what you want.
Is there any chance that this issue will be closed in short term (few weeks)? We still have crashes of Tomcat in our customer environments due to this. It's always "http-apr-80-Poller" problem as seen in provided attachment. Could someone take a look at it? We are still not able to simulate this issue with certainty though.
(In reply to Martin Hanus from comment #5) 1. Unlikely. There is no clue what the error is, and how to reproduce it. 2. I would suggest you to add the following setting to the catalina.properties file: org.apache.catalina.connector.RECYCLE_FACADES=true http://tomcat.apache.org/tomcat-7.0-doc/config/systemprops.html#Security That is better from security POV and protects connector from mis-behaving web applications. 3. Tomcat-Native 1.1.30 is available.
As far as I can tell from the provided information, this is a duplicate. If you still see this issue (or something like it) with the latest stable 1.2.x release and the latest stable release of a supported Tomcat version, please open a new bug. What we really need are steps to reproduce. Even if it doesn't reproduce reliable, a script that will trigger then problem (the quicker the better) is very helpful. *** This bug has been marked as a duplicate of bug 56313 ***