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 10.32.8.135]
Zlib: Compressed 0 to 2 : URL /pbs/cntrty/getReprots
[Wed Mar 26 02:24:22 2014] [info] [client 10.234.9.0] (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 10.234.9.0]" : 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
away.
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
Tomcat
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: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
