Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Chirag,
On 6/13/13 12:59 AM, Chirag Dewan wrote:
A little more digging in and I found out that only with SSL,tomcat
is creating a large number of sessions. I can see in the logs for
HTTP:
INFO: SessionListener:
sessionDestroyed('2E8DE01EE3F0D166FEFC8A45353CD9ED')
Now,in case of HTTPS I see a large number of such logs. So I
believe for HTTPS requests it is creating a session for every
request as compared to HTTP?
That seems odd, as web applications usually create sessions regardless
of the use of HTTP versus HTTPS. I suppose it's your web application,
so it could be doing anything at all.
This is my SSL setting in client:
public HttpTLSProtocolSocketFactory() { try { this.sslcontext =
SSLContext.getInstance("TLS"); TrustManager[] arrayOfTrustManager =
{ new DummyX509TrustManager() }; this.sslcontext.init(null,
arrayOfTrustManager, null); } catch (Exception localException) {
this.logger.log(Level.SEVERE, "Failed to created SSLContext: " +
localException.getMessage()); } }
public Socket createSocket(String paramString, int paramInt1,
InetAddress paramInetAddress, int paramInt2, HttpConnectionParams
paramHttpConnectionParams) throws IOException,
UnknownHostException, ConnectTimeoutException { if
(paramHttpConnectionParams == null) throw new
IllegalArgumentException("Parameters may not be null"); int i =
paramHttpConnectionParams.getConnectionTimeout(); SSLSocketFactory
localSSLSocketFactory = this.sslcontext.getSocketFactory(); if (i
== 0) return localSSLSocketFactory.createSocket(paramString,
paramInt1, paramInetAddress, paramInt2); Socket localSocket =
localSSLSocketFactory.createSocket(); InetSocketAddress
localInetSocketAddress1 = new InetSocketAddress(paramInetAddress,
paramInt2); InetSocketAddress localInetSocketAddress2 = new
InetSocketAddress(paramString, paramInt1);
localSocket.bind(localInetSocketAddress1);
localSocket.connect(localInetSocketAddress2, i); return
localSocket; }
Can different sockets create different sessions?
This isn't an SSL session issue, it's an HttpSession issue. The client
is irrelevant, except that you are not handling the Set-Cookie
response header Tomcat is likely sending to you. If you sent that
Cookie back to the server, you would likely eliminate all those extra
sessions and instead only create one (HTTP) session per client thread.
So for HTTP I am not creating any new sessions,same should be the
case for HTTPS. Right?
Only you know what your web application is doing.
The only thing which differs in my is the SSLSocketFactory
Implementation, which creates sockets.
Look at your webapp's code, not the client code.
You might want to write an HttpSessionListener that fires whenever an
HttpSession is created. Do something like this:
public void sessionCreated(HttpSessionEvent se)
{
new Throwable("Trace for session creation").printStackTrace();
}
It looks like you already have an HttpSessionListener (that's where
the INFO message above comes from), so maybe you could just modify
that one.
This will dump stack traces to stdout and tell you exactly where the
sessions are being created. then you can probably figure out why they
are being created in the first place.
Just a shot in the dark here : isn't there some set of conditions whereby Tomcat would set
a cookie sent back to the client, who would return it when the connection is HTTP, but not
when the connection is HTTPS ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
