tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: Tomcat 5.5.23 stops listening to requests on SSL port
Date Thu, 30 Apr 2009 16:04:14 GMT
Rahman Akhlaqur wrote:
> Hi 
>  
> I am having an issue with my Tomcat server not responding on the SSL port. I reported
this as a possible bug but this was rejected as a config issue. More info as below:
>  
> The Tomcat connector is configured as below
> 
> <!-- Define a non-SSL HTTP/1.1 Connector on port 8080 --> <Connector
> port="8080" maxHttpHeaderSize="8192" maxThreads="350" minSpareThreads="25"
> maxSpareThreads="75" enableLookups="false" redirectPort="8443"
> acceptCount="100" connectionTimeout="20000" disableUploadTimeout="true" />
> 
> <!-- Define a SSL HTTP/1.1 Connector on port 8443 --> <Connector port="8443"
> maxHttpHeaderSize="8192" maxThreads="150" minSpareThreads="25"
> maxSpareThreads="75" enableLookups="false" disableUploadTimeout="true"
> connectionTimeout="20000" acceptCount="100" scheme="https" secure="false"
> proxyPort="443"/>
> 
> <!-- Define an AJP 1.3 Connector on port 8009 --> <Connector port="8009"
> enableLookups="false" redirectPort="8443" protocol="AJP/1.3" />
> 
> The issue is that Tomcat stops listening on port 8443 after a while of running.
> This means no HTML is returned to end users browsers.
> 
> I know this as I am getting a HTTP error code 502 from the apache 2.2.4
> webserver that is proxying the request to Tomcat.
> 
> The setup I have is that SSL is terminated at a load balancer and forwards the
> request to port 8443 to apache, which then proxy passes the request to Tomcat
> to port 8443 and then Tomcat passes this request to the content server on port
> 443 (as this is a secure request).
> 
> One theory is that end users are abruptly terminating their session with Tomcat
> (by cancelling their secure requests or closing their browsers) and Tomcat is
> not closing the thread when this happens. Therefore running out of threads. I
> am not sure about this and need some way to prove it.
> 

This is a subjective comment from a person not really qualified in SSL 
matters.

First, the configuration you describe above sounds quite complex and 
relatively inefficient. Do you really need to have SSL end-to-end ? I 
mean, each step in the chain needs to set up an SSL channel and 
encrypt/decrypt everything, which is quite costly.  If the hops after 
the load-balancer are all in some internal network, you might gain quite 
a bit of efficiency by doing this non-SSL-wise.

Then, you are not really saying what kind of port the port 8443 on 
Apache is.
Then, how does Apache pass the request to Tomcat ? via which kind of 
connector (mod_proxy_http, mod_proxy_ajp, mod_jk ?) ?
(The reason I am asking is because if it was mod_jk, it can produce logs 
that are relatively detailed to diagnose this kind of problem).

Why is Apache even there, come to think of it ?

And then how does the request go from Tomcat to the content server ?

What is that content server ?  Could it be it that "stops responding" ?

Next, you mention a 502 response received by Apache.
That code means "invalid response from the upstream server".
It does not really mean "the upstream server is not responding" (that 
would be a code 503). So what makes you think that Tomcat is not 
responding to requests ?
Are there any kind of error messages in the Tomcat logs ?

When "Tomcat stops responding", can you make requests directly to Tomcat 
(without going through the load-balancer and Apache), and what happens 
then ?

And finally, considering the configuration, there are quite a few things 
that /could/ go wrong, with 4 hops involved.  I believe you are going to 
have to do much more investigation (and more systematic) to at least 
point out where something happens.
And show some log messages.




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message