Customer experiences a deadlock when different threads are calling SSLSocketImpl.read() and SSLSocketImpl.close() on the same SSLSocket. Below we have listed the thread dump.
 
Thread 1: the user code is something like
                                           
_input = _sslSocket.getInputStream();
...
_input.read(bytes, offset, length);
 
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.b(DashoA6275)
- waiting to lock <0xef5862e8> (a java.lang.Object)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.b(DashoA6275)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
- locked <0xef5862f0> (a com.sun.net.ssl.internal.ssl.SSLSocketImpl)
- locked <0xef586398> (a java.lang.Object)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
at com.sun.net.ssl.internal.ssl.AppInputStream.read(DashoA6275)
- locked <0xef5863a0> (a com.sun.net.ssl.internal.ssl.AppInputStream)

Thread 2: the user code is :
                  _sslSocket.close();

at com.sun.net.ssl.internal.ssl.SSLSocketImpl.h(DashoA6275)
- waiting to lock <0xef5862f0> (a com.sun.net.ssl.internal.ssl.SSLSocketImpl)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.b(DashoA6275)
- locked <0xef5862e8> (a java.lang.Object)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.close(DashoA6275)
at com.borland.security.csiv2.SSLConnection.close(SSLConnection.java:925)
at com.inprise.vbroker.GIOP.GiopConnection.close(GiopConnection.java:647)
- locked <0xef58fdf8> (a com.inprise.vbroker.util.IntMap)
at com.inprise.vbroker.GIOP.GiopProtocolAdapter.close(GiopProtocolAdapter

It is possible to call socket.read() and socket.close() at the same time for plain/normal socket. This should be also possible for SSLSocket.

Customer is creating SSLSockets by calling the sslSocketFactory.createSocket(socket, host, port, autoClose) method.

Customer is setting autoClose as "true" in their product, but it doesn't help.