Kanatoko wrote:
Andrew,
I figured out why sockOutput comes to null.
SSLSocketImpl class is used both from SSLSocket class and
SSLServerSocket class.
The problem occurs when SSLServerSocket instance uses(creates)
SSLSocketImpl
instance only for getting ServerHandshaker instance. The code is below.
-----From share/classes/sun/security/ssl/SSLServerSocketImpl.java
private void checkEnabledSuites() throws IOException {
//
// We want to report an error if no cipher suites were actually
// enabled, since this is an error users are known to make. Then
// they get vastly confused by having clients report an error!
//
synchronized (this) {
if (checkedEnabled) {
return;
}
if (useServerMode == false) {
return;
}
SSLSocketImpl tmp = new SSLSocketImpl(sslContext, useServerMode,
<=================== HERE!
enabledCipherSuites, doClientAuth,
enableSessionCreation, enabledProtocols);
ServerHandshaker handshaker = tmp.getServerHandshaker();
for (Iterator t = enabledCipherSuites.iterator(); t.hasNext(); ) {
CipherSuite suite = (CipherSuite)t.next();
if (handshaker.trySetCipherSuite(suite)) {
checkedEnabled = true;
return;
}
}
-----
This SSLSocketImpl instance 'tmp' does not handle any TCP( or SSL )
connections, so sockOutput is always null.
This method 'checkEnabledSuites()' is called only once for each SSLServerSocket
instances, So If you instantiates more SSLServerSockets, more file handle leak
occurs.
Yes, your analysis is correct. I think maybe need to polish the checking
of the connection states, so that the SSLSocketImpl.closeInternal() will
not send any messages (alter/warning message in the case) to peer
before a active connection established.
Because of another mail thread proposed by
[EMAIL PROTECTED], we would update the implementation of
checkEnabledSuites(). This is another factor that we should consider
during the update.
Thanks,
Andrew
I think we should patch SSLSocketImpl class. But I don't have a good fix.
