We are facing a scenario where in rare instances Websphere cores due to OutOfMemory error.  When we analyze the heap we see thousands of instances of SSLSocketImpl taking up the vast majority of available memory. 

Who is creating these SSLSocketImpl instances?
Why are they not getting cleaned up?

System:
Websphere 7
We run with two clones. 
We use EHCache for cahing across the clones. 
DB2 database

Any tips on why this might be happening or debugging strategies to determine the source of the SSLSocketImpl instances is appreciated.

My guess is you are having a backend system such as Web Service Host, Database or other EIS systems and you are taking to it over SSL. It is possible that the connections to those backend systems are NOT getting freed up for whatever reason. When you see the heap dump, do a 'netstat -an' on your server and see if you can find excessive connections to a particluar host.

Thanks Karun,

I suspect that the socket  objects are dead (closed but not cleaned up).  We have found at least two APARs related to such occurrences.  Both are closed and our libraries are up to date, but our suspiscion is that we have found another scenario.

If the connections are dead then we will not see anything with netstat.  However, your suggestion is still helpful, as it would either confirm or rule out excessive live connections.  If the connection close process is being bypassed by an exception the we might just see them.

Appreciate the response.  Thanks.

Patrick, sorry to piggyback on your question but we have a very similar problem: WebSphere 7.0 server fails with OutOfMemoryError. Post-mortem analysis using IBM HeapAnalyzer reports java/net/SocksSocketImpl as main leak suspect.
Have there been any new insights since you raised this?