Mark, On 4/7/18 6:57 AM, Mark Thomas wrote: > On 06/04/18 22:10, dharmon wrote: >> environment: >> tomcat 8.5.23 >> CentOS 6.9 >> jdk8u162 b12 >> >> I recently upgraded from tomcat 7.0.61/jdk8u92 to tomcat 8.5.23/jdk8u162. >> Our application war file on tomcat7 has cpu >75% idle per vmstat several >> hours after tomcat start. Same war file on same server with tomcat8.5.23 has >> cpu 0% idle per vmstat several hours after restart. Same server with similar >> request load. Server has 4 CPUs. War file processes https REST web service >> requests. >> >> I used jvisualvm to perform CPU profiling and the method with most self time >> is org.apache.tomcat.util.buf.Utf8Decoder.decodeHasArray. jstack shows there >> are 12 https-jsse-nio-8443-exec-### threads always in runnable state[1]. >> They have been in this state for several hours. It appears as if it's stuck >> in infinite loop. Using the thread's nid and lsof, I believe the tcp/https >> connection associated with these threads are no longer >> connected/established. >> >> Any known issues that could be causing this problem? I also tried using the >> NIO2 connector with same issue. > > None I am aware of. I wouldn't expect the connector to make any difference. > >> I'm on a closed network, thus unable to show jvisualvm screen shots or >> verbose stack traces. > I've taken a good look at the relevant code and nothing immediately > jumps out as a potential cause of this. > > It sounds as if this is fairly easy to reproduce so I would suggest > configuring your Tomcat instance to support remote debugging and when it > happens again step through the relevant code to see why /exactly where > it is looping. The aim is to provide us with enough information to > ideally reproduce it but - as a minimum - provide an explanation that > can be used to support a change to fix it.
+1 This has "edge case" written all over it. I suspect once we capture a stream/string being read/converted, we will find that something like Java's double-precision bug[1] where the decoder oscillates between two states. Does Tomcat do its own UTF-8 decoding because the JVM doesn't have a facility to convert from ByteBuffer to CharBuffer? That seems like something the JVM really should be providing... Most of the code in that method is fairly old. Has the Java API caught up with us, yet? -chris [1] http://www.exploringbinary.com/java-hangs-when-converting-2-2250738585072012e-308/ --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
