tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: Apache HTTPD + Tomcat restarts
Date Mon, 15 Apr 2013 23:02:27 GMT
Shanti Suresh wrote:
> Hi all,
> Apologies :-)  I was expecting a simple yes/no response.

Well, you wrote that you wanted to know our thoughts.  Yes or No would not have been an 
appropriate response to that, so we elaborated  a bit.

> On Mon, Apr 15, 2013 at 4:01 PM, André Warnier <> wrote:
>> Mark Eggers wrote:
>>> Apache HTTPD modules do not influence how Apache Tomcat runs.
> That's what I thought.
>>> If that cures your problem, then you should take things up with the
>>> mod_security mailing list.
>>> Thank you!  I am not running mod_security.
>>> Versions of:
>>> Apache HTTPD
>> Server version: Apache/2.2.3
>>  Apache Tomcat
>> apache-tomcat-7.0.23
>>  Java
>> jre-1.6.0-sun.x86_64
>>> Operating system and version
>> RedHat Linux 2.6.18-348.2.1.el5
>>> Method you use to connect Apache HTTPD to Apache Tomcat
>> mod_proxy + mod_proxy_http
>>> Text of the Internal Server Error. If you've not configured an error page
>>> for the 500 error, then you'll see a stack trace if it's from Tomcat.
> Don't have the Internal Server error's exact text.  There was no stack
> trace from Tomcat.  It was simply an Internal Server 500 error text on the
> Apache side.  I have not configured an error page.  Gosh!  I don't
> recollect anything on the Tomcat direct-hit either.  Otherwise, I would be
> a happy camper.
>> And you are guessing quite a lot. With the information provided by the OP
>> initially, I was going to ask if Apache httpd and Tomcat were located in
>> the same city and/or connected in any way. Oh, and he also mentioned a
>> loadbalancer cache. Either Pid or Quantum Theory might be of help here.
> My apologies.
> Here's all I have from Apache's error log.  Several entries looking like so
> starting at:
> ----------
> [Thu Apr 11 21:24:14 2013] [error] [client nnn.nnn.nnn.nnn] (70007)The
> timeout specified has expired: proxy: error reading status line from remote
> server
> [Thu Apr 11 21:24:14 2013] [error] [client nnn.nnn.nnn.nnn] proxy: Error
> reading from remote server returned by /web-app/url1/
> [Thu Apr 11 21:24:55 2013] [error] [client nnn.nnn.nnn.nnn] proxy: Error
> reading from remote server returned by /web-app/url2, referer:
> [Thu Apr 11 21:24:55 2013] [error] [client nnn.nnn.nnn.nnn] (70007)The
> timeout specified has expired: proxy: error reading status line from remote
> server, referer:
> ---------
> Apache and Tomcat are in the same city,  and in the same data-center.
> And Apr 11 21:05 is when I restarted Apache after removing several unused
> modules - hard stop and start.  The way I restarted Apache is:
> sudo /usr/sbin/service httpd stop
> sudo /usr/bin/servive httpd start

So you wrote that you restarted Apache at 21:05, and that about a minute later you had 
some Server Errors.  The log messages above are dated of 21:24. That is 20 minutes after 
the restart, not really 1 minute.
If I have to express a thought based on that conflicting information, then I would guess 
that the errors are probably not related to the restart of Apache per se.
It may just have been a coincidence.  Although using the term "coincidence" for events 
that happen at a 20-minute interval on a production server seems a bit of a stretch.

The (edited) error log shown above just tells us that at 21:24:14, Apache+mod_proxy 
determined that there was a timeout following an earlier request to Tomcat.  In other 
words, Apache proxied a request to Tomcat, and Tomcat did not respond in time, so 
mod_proxy gave up waiting and aborted the request with an error.
And then again 40 seconds later at 21:24:55, same issue.
Now why at that time Tomcat did not respond in time (or at all), is a mystery as well for

us as for you.
There is nothing there that would tell us when the request which failed was actually 
started. We just see when it failed.
Maybe by looking at the same time at the Apache access log and at this error log, you can

determine which requests failed, and figure out if there is some logical reason at the 
Tomcat level.  Maybe these requests were just so that Tomcat really took "too long" to 
answer, and mod_proxy lost patience...
In any case, there is nothing there that specifically links the Apache restart, with the 
errors that happened later.
If Tomcat tried to send a response later (after Apache httpd timed-out), then there should

probably be an error message also in the Tomcat logs, since it would try to write back a 
response onto a connection that did not exist anymore.
Have you checked the Tomcat logs ? (which may be in /var/log/daemon, depending on the 
script which starts Tomcat).

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message