EasySSLProtocolSocketFactory written by Oleg uses the SSL libraries which are under com.sun.net.ssl as opposed to the ones you suggested which are under javax.net.ssl. There is no getClientSessionContext() method when using the SSL libraries from com.sun.net.ssl. It is only under javax.net.ssl. I found a modified version of Oleg's EasySSLProtocolSocketFactory class online which uses the javax.net.ssl libraries instead. With this modified version, I was able to use the methods you suggested (setSessionCacheSize, etc) but I wasn't sure I was using them in the correct place and no matter what I did, it didn't seem to make any difference. (I was trying to set these within the getEasySSLSocketFactory() method.) >>I think the best place to invalidate the session is from a custom >>connection manager in its releaseConnection method like so:
>>((SSLSocket) conn.getSocket()).getSession().invalidate(); I'll try this out. Thanks again for your help. Jeremy Hicks Novell, Inc., the leading provider of information solutions http://www.novell.com >>> Ortwin Glück [EMAIL PROTECTED]> 7/7/2006 2:33 AM >> ( mailto:[EMAIL >>> PROTECTED]> ) Jeremy Hicks wrote: > We are using the EasySSLProtocolSocketFactory written by Oleg which > is under com.sun.net.ssl.*. Huh, what is under com.sun? > I wasn't able to see a method for > SSLContext called getClientSessionContext(). http://java.sun.com/j2se/1.4.2/docs/api/javax/net/ssl/SSLContext.html#getClientSessionContext() > If there is a known way > to invalidate the session using this class, that would be great. With > this class we are getting, what appears to be, one full handshake > that is being shared across all threads that are running instead of > getting one full handshake for each thread (which is what a browser > does). Yes, that's true. This implementation is not perfect. It's a basis. We happily accept patches, however. > However, since I couldn't find that method, instead I tried a > modified version of the EasySSLProtocolSocketFactory class which uses > the javax.net.ssl.* classes. I fail to understand... > Using that, it seems that ALL SSL > handshakes are full and that none of them are abbreviated. Maybe you are not keeping any SSL sessions? > It didn't > seem to matter what I set the session cache size or session timeout > to, I always got the same results. (I was trying to set these within > the getEasySSLSocketFactory() method.) It also didn't seem to matter > if I used the MultiThreadedHttpClientManger or my own that > force-closes the HTTP connections. Where should I be making the call > to SSLSocket.getSession() to try and invalidate the session there? I think the best place to invalidate the session is from a custom connection manager in its releaseConnection method like so: ((SSLSocket) conn.getSocket()).getSession().invalidate(); > Am I missing something basic here? If I'm not being clear enough, > please let me know. > Hope that helps Ortwin Glück > Jeremy Hicks Novell, Inc., the leading provider of information > solutions http://www.novell.com ( http://www.novell.com/ ) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
