-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Konstantin,
On 10/22/12 1:19 PM, verlag.preis...@t-online.de wrote: > I'm running Tomcat 7.0.32 with Java 1.7.0_09 (64-bit) on Windows > Server 2008 R2 (64-bit), behind IIS 7.5 with ISAPI Redirector > 1.2.37. For the AJP connection, I used the AJP-APR connector (with > Tomcat Native 1.1.24). > > 1) This worked perfectly fine since the initial setup of the > server 3 months ago (however with lower version numbers of Tomcat > and Java), but 3 days ago, suddenly the JVM crashed, with following > crash report: Java 1.7.0_09 was only released a few days ago. Perhaps that could be the problem? > # # A fatal error has been detected by the Java Runtime > Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at > pc=0x000000007160e291, pid=4028, tid=4060 # # JRE version: > 7.0_09-b05 # Java VM: Java HotSpot(TM) 64-Bit Server VM (23.5-b02 > mixed mode windows-amd64 compressed oops) # Problematic frame: # V > [jvm.dll+0xae291] > > At a first glance this seems like a JVM bug (as the current thread > is GCTaskThread), but when I googled for it, most sources say that > this is mostly caused by bugs in JNI code / a library that uses > JNI [1]. That sure looks like a JVM bug, but it's always possible that tcnative gave the JVM a bad pointer and so the bug is in tcnative. Can you provide the full back-trace? > Unfortunately, for me this means that I have to consider the APR > connectors on 64-bit Windows as broken (at least for the time > being), and therefore I switched to the NIO/BIO ones and removed > the TC native library. If I will get a JVM crash again, then this > would probably mean that it was not the fault of the TC native > library. ;) You shouldn't have to abandon tcnative entirely... that is, you can just switch connectors and leave the native library there doing (virtually) nothing. > 2.) After I switched to the AJP-NIO connector, I got the following > stacktrace in catalina.log: Okt 20, 2012 2:58:51 PM > org.apache.coyote.ajp.AjpNioProcessor process SEVERE: Error > processing request java.nio.BufferOverflowException at > java.nio.HeapByteBuffer.put(HeapByteBuffer.java:183) at > org.apache.coyote.ajp.AjpNioProcessor.output(AjpNioProcessor.java:281) > > at org.apache.coyote.ajp.AbstractAjpProcessor$SocketOutputBuffer.doWrite(AbstractAjpProcessor.java:1122) > at org.apache.coyote.Response.doWrite(Response.java:504) at > org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:383) > > at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:462) > at > org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:334) > > at org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:283) > at > org.apache.catalina.connector.Response.finishResponse(Response.java:514) > > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:434) > at > org.apache.coyote.ajp.AjpNioProcessor.process(AjpNioProcessor.java:184) > > at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:585) > at > org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1653) > > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > > at java.lang.Thread.run(Thread.java:722) > > Maybe this could be related to bug 53119 [2] (the stack traces look > very similar)? (However I have not yet tried if this is > reproducible with the given testcase - when I tested it back then > with Tomcat 7.0.27's AJP-NIO connector, I could not reproduce the > error). Definitely file that in Bugzilla: it might actually be an identical issue that needs to be fixed in the non-APR flavor of the AJP connector (though Konstantin Kolinko is usually quite thorough and I wouldn't have expected a mirror-bug to have slipped through the cracks). > So, currently I have switched to the AJP-BIO connector. Well, the good news is that httpd should be handling the HTTP pipelining, keepalives, etc. and so the benefits of using APR are lessened in general and so switching-away from APR shouldn't be that traumatic. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCHB9EACgkQ9CaO5/Lv0PANtQCePjtPlZcXu07Kl4+W5PwvUTMD 3HUAn3pFP7neIgy4EwLq10m3wm34CBWc =KJDf -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
