Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (nike.apache.org: domain of aw@ice-sa.com designates
 212.85.38.228 as permitted sender)
Message-ID: <49E5A192.3000601@ice-sa.com>
Date: Wed, 15 Apr 2009 10:57:54 +0200
From: =?ISO-8859-1?Q?Andr=E9_Warnier?= <aw@ice-sa.com>
Reply-To: aw@ice-sa.com
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: mod_jk Problem
References: <000901c9bd92$21e96ab0$65bc4010$@mn>
 <3938bb7b0904150059k6ed5ae65u3a507cae935457b9@mail.gmail.com>
In-Reply-To: <3938bb7b0904150059k6ed5ae65u3a507cae935457b9@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org