Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (athena.apache.org: domain of aw@ice-sa.com designates
 212.85.38.228 as permitted sender)
Message-ID: <51B9D8DF.4080607@ice-sa.com>
Date: Thu, 13 Jun 2013 16:36:15 +0200
From: =?UTF-8?B?QW5kcsOpIFdhcm5pZXI=?= <aw@ice-sa.com>
Reply-To: Tomcat Users List <users@tomcat.apache.org>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: OOME issue in Tomcat 6.0.18(with SSL)
References: <1371013274.27643.YahooMailNeo@web190703.mail.sg3.yahoo.com>
 <51B88969.6050605@christopherschultz.net>
 <1371099572.21241.YahooMailNeo@web190702.mail.sg3.yahoo.com>
 <51B9D5D6.2040202@christopherschultz.net>
In-Reply-To: <51B9D5D6.2040202@christopherschultz.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org