This content has been marked as final. Show 1 reply
I have seen an almost identical problem within an Apache CXF web service. In my situation the end of the stack looks almost identical, stuck forever (apparently) inside the native Deflater.deflateBytes.
In my situation I have seen this with two threads, each independently using GZIPOutputStream.
I am really starting to think that there is a thread safety issue with the native GZIP code - two independent objects in two threads are simultaneously zipping and both get stuck with 100% CPU utilization in the native code. Interestingly my situation is also in the close processing, but not inside the finish processing. Of all the situations I see with searching for similar situations (search the web for Deflater.java:306) there seems to be a set of common circumstances:
* Exactly the same last few levels on the stack (ending in Deflater.deflateBytes (Native Method)
* Two threads interacting with GZIP
* Often seems to relate to close processing (perhaps a short data remainder problem?)
My situation is documented here:
Salient details of thread dump:
"http-thread-pool-8080-(18)" - Thread t@950
at java.util.zip.Deflater.deflateBytes(Native Method)
- locked <21b0c5> (a java.util.zip.ZStreamRef)
- locked <132ba84> (a java.util.zip.GZIPOutputStream)