tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: timeout
Date Sun, 30 Mar 2014 22:30:12 GMT
Vicky B wrote:
> HI All,
>   Below are the inforamtion
>   OS : Solaris 5
>   apache httpd : 2.2
>   tomcat : 7
>     log : error.log
> message :
> [Wed Mar 26 02:24:22 2014] [debug] mod_deflate.c(616): [client]
> Zlib: Compressed 0 to 2 : URL /pbs/cntrty/getReprots
> [Wed Mar 26 02:24:22 2014] [info] [client] (131)Connection reset
> by peer: core_output_filter: writing data to the network

As Chuck and Mark already mentioned, you are still not doing what is requested of you, and

it is still annoying.
But at least now, there is *some* information to go on with.

First, stop your fixation on a "timeout" value somewhere (you have still not really told 
us where that value was), and by all means restore the default values if you have been 
playing with them.  These default values are selected by people who know what they are 
doing, to cover the majority of real-world cases.  If you start changing them without 
knowing exactly what you are doing, you are most probably doing more harm than good.
Repeat : do not change the default values of anything, before you have identified a real 
problem and are sure that this parameter acts on that problem, without unwanted 
side-effects somewhere else.

Now about the log lines above, and particularly the second one (the first one ´not being

an error) :
- they are Apache httpd log lines, not Tomcat log lines
- they provide the IP address of the client
- and the second line *is* an error, at the Apache httpd level

You have not shown us any information yet that would indicate that there is an error at 
the Tomcat level, but let's just be a bit rational with the information at hand.

In the schema that Mark gracefully provided (reproduced below), Apache httpd is talking to

two sides :
- the browser side, via HTTP
- the Tomcat side, via AJP

Browser   <--->    Apache HTTPD   <---->   Apache Tomcat
(various) port 80  version 2.2.?    AJP    version 7.0.?
                    Solaris 5?              Java ?

and the log line says
- "[client]" : that seems clear to me; if Apache httpd is talking about a 
client in this case, it must be the browser, right ? and it even provides this client's IP

address, to verify the assumption
- "Connection reset by peer" : that means that this client closed the connection, which 
means that Apache httpd cannot ..
- "writing data to the network"
and therefore it declares and logs an error, because it wanted to write something to the 
client and it cannot do that on a closed connection.

So, using the evidence which you have yourself provided, what makes you think that there 
is a "time-out" somewhere in your configuration, which causes this ?

It is not a time-out at the server level that we are seeing here.  What we are seeing is 
that the client "went away" and closed its connection to the server, while the server 
wanted still to send it some information (the application's delayed response, most likely).

If a time-ou there is, using the available evidence, it is probably on the part of the 
user sitting in front of that browser, who reached the end of his own patience waiting for

a response from the application, and decided to click somewhere else to pass the time in a

more agreeable fashion.

So, as someone else already answered you a long time ago (as a one-liner and from his 
phone if I remember correctly), it looks like your first order of business should be to 
find out why your application takes so long to respond, that users get impatient and walk


Unless you can show us some hard evidence that something else between your application and

the browser is holding up the application response.. (*)

Let me insist a little bit : if Apache httpd had sent some request to Tomcat via mod_jk 
and AJP, and it was that connection which timed out, then you would not get the above 
message in your Apache httpd logs.  You would get another kind of message, not one saying

that the client closed the connection to Apache httpd.

(*) One such possible scenario - as Mark also mentioned - is that the connection schema 
may be somewhat different, as follows :

Browser   <--->   firewall/gateway  <---->  Apache HTTPD   <---->   Apache

and that it is this firewall/gateway which is dropping a connection if it sees nothing 
happening on it for a while.  For Apache httpd, that would look exactly the same as if it

was the browser going away.
But if so, there is no chance at all for us here on this list to find out about that, and

you will need to talk to the network people responsible for that equipment.

If you think (based on some evidence, not just guesses) that your application is not 
really taking too much time in responding to a request, and you think that it must be 
something between Tomcat and the browser that is dropping the connection too quickly, then

you should do the following :
- configure both Apache httpd and Tomcat to provide an "access log", with sufficient 
information in these logs to determine when a request is received from the browser, and 
when the response is being sent by Tomcat
- and then compare these two logs
And then, if you see that Tomcat is sending (or trying to send) a response within that 
time that you think is reasonable, and you still see that Apache httpd cannot send that 
response to the browser because that client connection has dropped in the meantime, you 
should :
- find the user and ask him/her why he/she clicks away without waiting for the response
   (maybe they just have a defective mouse)
- and if that is not the reason, then find the person responsible for the in-between 
equipment and ask them why their junk closes the connection before your application has a

chance to respond

And now, just to finish this post on a confusing note : "connection reset by peer" 
messages in the Apache httpd error log, are not necessarily on their own an indication 
that there is a serious problem (unless they occur very frequently).  Web users in general

*are* often impatient and often poorly-trained or poorly focused, and they *do* tend to 
click all over the place without waiting for the poor webserver to finish sending them 
what they requested in the first place.  That is just a fact of life, and anyone running a

professional webserver is used to see such messages in the logs (at least if their log 
level is set to INFO).
Of course, they *do* indicate a problem, if 50% of the requests to your application end up

with such a message.

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

View raw message