Re: [Jessie-discuss] Bug when closing stream

[Martin Egholm Nielsen]

> > > > > > > > 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...

> I meant you should use 'java.net.ServerSocket.accept()' to get a  plain 
> TCP socket, then call  'javax.net.ssl.SSLSocketFactory.createSocket 
> (Socket,String,int,boolean)' to wrap that socket with an SSL layer.  You 
> can then call 'close()' on the plain socket if you need to.

Aaah, clever clever! I'll do that - and wrap the wrapped socket in a new 
Socket wrapper for passing the close() to the real Socket, but the rest 
to the SSLSocket.

Thanks,
 Martin