WenDong Zhang wrote:
I've the same problem too, and I found that if the tomcat response time is
long, you need to set connection_pool in your workers.properties.
Ok, let me be more explicit.
What you suggest above may work, /if/ the underlying reason for the
problem meets certain criteria. But is is not a generic solution to
what the OP indicates. We have no idea if Tomcat's response is slow or
not, or if it is even requests to Tomcat that are involved. (The OP
indicated that Tomcat itself was still fine, it was Apache which was not
responding anymore; I don't know exactly what he meant by "Tomcat is
still fine", but let's take this at face value).
If you start from the beginning (and simplifying a bit):
- the browser sends a HTTP request to Apache
- if the network is OK, and the host is not overloaded, Apache receives
this request.
- if Apache has a child or thread free to handle this request, it passes
the request to it
- if mod_jk in the child/thread determines that this request should be
handled by Tomcat, it opens a connection to Tomcat to pass the request
(or it re-uses an existing connection if it still has one, for
efficiency). (If the request is not for Tomcat, mod_jk declines it and
it is handled locally by something in Apache.)
- if the Connector at the Tomcat side is not overloaded, it accepts the
request, and if it still has threads to spare, it starts a thread to
handle the request
- the thread takes a while (short/long) to process the request and
generate a response
- during that time, mod_jk waits for the response
- when the response starts arriving back from Tomcat, mod_jk starts
writing it back to the pipe that is ultimately connected to the client
browser.
- when the response has been entirely produced by the Tomcat thread, it
is done and can rejoin the pool of available threads
- similarly, when mod_jk has received the entire response, it can return
this connection (to Tomcat) to the pool
- similarly, the Apache thread/child that was processing this request
can go back to the available pool
- etc...
Now at any time during the above, a number of things can happen :
- the user may get impatient because it takes a long time for Tomcat to
produce the response. So he clicks on the cancel or "refresh" icon, or
clicks on another link. So when mod_jk receives a piece of the response
from Tomcat and tries to forward it to the client, it finds a closed
socket, and it prints a warning.
- the request may not be handled by Tomcat, but instead by a buggy
application in Apache itself, which gradually paralises Apache.
- between the browser and the server, there is some equipment that
decides that nothing has happened on this connection for a long time,
and closes it down. The browser gets an error, and so does mod_jk when
it tries to write to the client.
- mod_jk tries to connect to Tomcat, and gets refused because the Tomcat
connector has no more "queued-up connection slots" available on that port.
- Tomcat accepts the connection and puts it in the queued-up
connections, waiting for an available thread to process the request.
But other previous requests take a long time to process, so after 2-3
minutes, the browser decides that the server is not responding, closes
the connection and displays an error page to the user.
And mod_jk finds a closed client socket when ultimately it wants to send
the Tomcat response to the client.
- there are genuine network problems between the client and the server,
causing connections to drop
- the sysadmin has played around with the setup of Apache and mod_jk and
the JVM and Tomcat to the point that Apache accepts 10,000 requests per
second, but the backend Tomcat can only handle 100 at any one time.
- there is a bug in a webapp that causes it to leak resources over time,
gradually slowing down Tomcat
And so on...
The point is, there are many situations that are possible, and there is
not one magic fix for them all.
You have to know what exactly is the problem (or at least have a clue),
before you start modifying parameters left and right blindly, and
possibly making the situation even worse.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
