|
From: | Martin Egholm Nielsen |
Subject: | Re: [Jessie-discuss] Bug when closing stream |
Date: | Thu, 30 Jun 2005 09:45:20 +0200 |
User-agent: | Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050319 |
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< ---
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 everI would guess that it is indeed a concurrency problem.having a chance...
--- 8< 8< 8< ---
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.But then there is no way to kick an ongoing client connection?
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...
// Martin
[Prev in Thread] | Current Thread | [Next in Thread] |