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. customer .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.
Posted Date : 2005-12-02 22:25:03.0

N/A

This deadlock can occur if one thread calls sslSocket.close() at the same time another thread reads a close_notify message from the remote peer via inputStream.read(). The problematic locks are the closeLock and the SSLSocketImpl object. This issue is unrelated to layered sockets.

An unobfuscated stacktraced obtained from an instrumented Mustang build is shown below. It is not clear what the best way to fix this problem is. It might be possible to eliminate closeLock completely, which is only used in the two places involved in this deadlock.

---
Found one Java-level deadlock:
=============================
"closer":
  waiting to lock monitor 0x000fe6f8 (object 0xf41f4848, a com.sun.net.ssl.internal.ssl.SSLSocketImpl),
  which is held by "main"
"main":
  waiting to lock monitor 0x000fe760 (object 0xf4202950, a com.sun.net.ssl.internal.ssl.SSLSocketImpl$CloseLock),
  which is held by "closer"

Java stack information for the threads listed above:
===================================================
"closer":
	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.getConnectionState(SSLSocketImpl.java:589)
	- waiting to lock <0xf41f4848> (a com.sun.net.ssl.internal.ssl.SSLSocketImpl)
	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.closeInternal(SSLSocketImpl.java:1322)
	- locked <0xf4202950> (a com.sun.net.ssl.internal.ssl.SSLSocketImpl$CloseLock)
	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.close(SSLSocketImpl.java:1230)
	at Test$2.run(Test.java:67)
	at java.lang.Thread.run(Thread.java:626)
"main":
	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.closeInternal(SSLSocketImpl.java:1319)
	- waiting to lock <0xf4202950> (a com.sun.net.ssl.internal.ssl.SSLSocketImpl$CloseLock)
	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1588)
	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:877)
	- locked <0xf41f4848> (a com.sun.net.ssl.internal.ssl.SSLSocketImpl)
	- locked <0xf41f48d0> (a com.sun.net.ssl.internal.ssl.SSLSocketImpl$ReadLock)
	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:689)
	at com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:75)
	- locked <0xf41f4940> (a com.sun.net.ssl.internal.ssl.AppInputStream)
	at com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:50)
	- locked <0xf41f4940> (a com.sun.net.ssl.internal.ssl.AppInputStream)
	at Test.main(Test.java:86)

Found 1 deadlock.
---
Posted Date : 2005-12-03 01:39:38.0

Fix has been reintegrated into 1.4.2_17-rev-b14.
Posted Date : 2008-05-30 19:44:08.0