Thomas Boniface wrote:
The file descriptor peak show up in our monitoring application. We have
some charts showing the number of file descriptors owned by the tomcat
process (ls /proc/$(pgrep -u tomcat7)/fd/ | wc -l).
The calatalina.out log shows errors, the most frequent being a
java.io.IOException: Broken pipe.
[..]
A "broken pipe", from the server perspective while sending a response to the client, is a
rather usual thing. It usually means that the (human) client got tired of waiting for a
response, and clicked somewhere else in the browser (maybe a "cancel" button; maybe he
closed the window; etc..). The browser would then immediately close the connection with
the server, and when the server eventually tries to write anything else to that
connection, the "broken pipe" exception would be the result.
With the numbers you quoted previously regarding the number of simultaneous client
sessions, it doesn't look extraordinary that this would happen regularly.
Maybe the thing to investigate here is whether your server is really so slow in answering
clients, that a significant portion of them do get tired of waiting and get an
irresistible urge to click elsewhere..
Apart from the human client, browsers themselves have a built-in timeout for waiting for a
server response, and will themselves give up after a while. That is on the order of 4-5
minutes after sending the request and not receiving anything from the server in response.
Some applications are such that they can sometimes take more than that to be able to send
a response. In such cases, to avoid the browser timeout (and connection close), there are
"tricks" to use, to send intermediate kind of "wait message" to the browser, so that it
does not hang up.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
