Hi Casey,
I just encountered a problem in Jessie when a SSLSocket was
closed:
Exception in thread "KeepAlive cleaner"
java.lang.ArrayIndexOutOfBoundsException
--- 8< 8< 8< ---
at org.metastatic.jessie.provider.SSLSocket.close
(Unknown Source)
--- 8< 8< 8< ---
I would guess that it is indeed a concurrency problem.
However, it's not trivial to make it thread safe, because one
thread may be "caught" in a blocking read-operation, hence the
mutex may be locked forever without the second thread ever
having a chance...
--- 8< 8< 8< ---
But then there is no way to kick an ongoing client connection?
Yes, you can forcibly close the underlying TCP socket. The JSSE
API lets you wrap an existing socket with an SSL layer, and you
can close that socket if you need to.
Yes, but I get the SSLSocket from the SSLSocketServer's "accept()":
public Socket accept() throws IOException
{
SSLSocket socket = new SSLSocket();
...
return socket;
}
and then SSLSocket's "underlyingSocket" field is null.
But even in the case it's not null, there is no way to fetch it if
from SSLSocket :-)
However, a "solution" for me would be to have the SSLSocket's
"close" method invoke "super.close()", but I guess there is much
cleaning up that is spoiled then...