Under heavy load I see lot of threads getting locked when GZipping and decompressing the JSP file. The thread dump looks like below. Seems to be coming from "header.jsp" which is of size 14Kb.
http-0.0.0.0-8080-304" daemon prio=3 tid=0x0000000008bcc000 nid=0x302 runnable [0xfffffd7de7bc2000]
java.lang.Thread.State: RUNNABLE
at java.util.zip.Deflater.deflateBytes(Native Method)
at java.util.zip.Deflater.deflate(Deflater.java:306)
- locked <0xfffffd7e589078e8> (a java.util.zip.ZStreamRef)
at java.util.zip.DeflaterOutputStream.deflate(DeflaterOutputStream.java:159)
at java.util.zip.DeflaterOutputStream.write(DeflaterOutputStream.java:118)
at java.util.zip.GZIPOutputStream.write(GZIPOutputStream.java:72)
- locked <0xfffffd7e58524d28> (a java.util.zip.GZIPOutputStream)
at java.util.zip.DeflaterOutputStream.write(DeflaterOutputStream.java:91)
at com.pinksheets.common.web.cache.ServletOutputStreamWrapper.write(ServletOutputStreamWrapper.java:24)
at java.io.OutputStream.write(OutputStream.java:99)
at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:202)
at sun.nio.cs.StreamEncoder.implWrite(StreamEncoder.java:263)
at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:106)
- locked <0xfffffd7e58524d48> (a java.io.OutputStreamWriter)
at java.io.OutputStreamWriter.write(OutputStreamWriter.java:190)
at java.io.BufferedWriter.write(BufferedWriter.java:170)
- locked <0xfffffd7e58524d48> (a java.io.OutputStreamWriter)
at java.io.PrintWriter.write(PrintWriter.java:382)
- locked <0xfffffd7e5824bd80> (a java.io.BufferedWriter)
at org.apache.jasper.runtime.JspWriterImpl.flushBuffer(JspWriterImpl.java:119)
at org.apache.jasper.runtime.JspWriterImpl.write(JspWriterImpl.java:326)
at org.apache.jasper.runtime.JspWriterImpl.write(JspWriterImpl.java:342)
at org.apache.jsp.include.header_jsp._jspService(header_jsp.java:2032)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
A few corollary links:
We are experiencing similar issues - our best theory so far is that the Java code (or the way it is using the underlying zlib backing library) can cause a thread to spin off into space this way. So far the only way we've been able to prevent it is to not GZip responses - but we'd rather pay the 100% CPU cost (as the other threads are still highly responsive) than not GZIP them. It's been months since you posted; do you have any other information to share?
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With