Probable JDK6 regression: SSLSocketImpl leak
jaroslav.bachorik at oracle.com
Fri Mar 21 15:43:30 UTC 2014
On 21.3.2014 16:37, Nathan Bryant wrote:
> Looking for some advice on how to debug an issue that's hitting our
> production stack.
> We have a grails app that's using apache httpclient 4.3.3 for transport to
> our backend tier over SSL. This worked fine for a long time but started to
> leak after our latest push.
> Symptoms: heap dump shows a large number of SSLSocketImpl instances (and
> associated byte and SocksSocketImpl) that can not be reclaimed. Clicking
> through everything in jmap, I can not find a path to the rootset (the paths
> to rootset query times out). There are references from finalizers, but I am
Would it be possible to use more production-ready tools to analyze the
heap? Like MAT or VisualVM? You should be able to get more meaningful
information out of them.
> consistently seeing "Number of objects pending for finalization: 0" via
> jhat and via jmap -finalizerinfo and other heap analysis tools. Thus, these
> are objects that "should" be reclaimed by GC.
> The finalizer thread itself appears to be idle:
> "Finalizer" daemon prio=10 tid=0x0000000001dcc000 nid=0x2437 in
>> Object.wait() [0x00007f3b8f5f4000]
>> java.lang.Thread.State: WAITING (on object monitor)
>> at java.lang.Object.wait(Native Method)
>> - waiting on <0x0000000180014918> (a java.lang.ref.ReferenceQueue$Lock)
>> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:133)
>> - locked <0x0000000180014918> (a java.lang.ref.ReferenceQueue$Lock)
>> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:149)
>> at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:189)
> The app works on:
> $ java -version
>> java version "1.6.0_27"
>> OpenJDK Runtime Environment (IcedTea6 1.12.6)
>> OpenJDK Client VM (build 20.0-b12, mixed mode, sharing)
> But fails on:
> $ java -version
>> java version "1.6.0_30"
>> OpenJDK Runtime Environment (IcedTea6 1.13.1) (6b30-1.13.1-1ubuntu2~0.12.04.1)
>> OpenJDK 64-Bit Server VM (build 23.25-b01, mixed mode)
> It also fails on the client/32-bit version of 1.6.0_30.
> If these objects are pinned by references from native code, I am
> assuming this doesn't show up in the heap dump?
More information about the discuss