tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <>
Subject Re: java.lang.OutOfMemoryError: Java heap space
Date Tue, 06 Oct 2009 11:58:03 GMT
On 05.10.2009 22:04, André Warnier wrote:
> André Warnier wrote:
> ...
> and still wants to add something :
> - a new KeepAlive connection is made from the browser to Apache (httpd).
> - then a request comes in on that connection, and it happens to be one
> that gets forwarded to Tomcat.  So a mod_jk connection is made to
> Tomcat, Tomcat allocates a thread for it.
> - I would imagine that mod_jk must pass on to Tomcat the fact that this
> is a KeepAlive connection, so that Tomcat would know that its thread for
> that connection, should also wait for subsequent requests.
> - so now the webapp/thread generates the response to the first request,
> and waits on the connection for more requests.
> - however, the browser does send more requests to Apache, but these are
> not ones that get forwarded to Tomcat (for example, they are for items
> that Apache serves locally) ...
> So now I wonder about how Apache + mod_jk + Tomcat react in such a
> situation.  Do the mod_jk connection +Tomcat thread keep waiting anyway,
> and how long ?

No in general. mod_jk only kicks in after a new request arrived over
such a connection. mod_jk is agnotic about whether the rquests came over
the same connection or not, even whether they belong to the same user or

But: in case you are using a prefork MPM, each connection gets assigned
to one process having one thread. This process has a connection pool of
size 1 to each backend and the backend ties a dedicated thread to that
connection (unless using tcnative). So in this case, it is a yes.
Between two Keep Alive requests, there's no way of letting the Apache
process handle other requests and thus the backend connection and
backend thread are blocked waiting for the next request. That's why e.g.
NTLM has a chance to work via mod_jk in combination with prefork.

So here's a use case for the worker MPM, because then one client
connection still blocks one Apache thread. But multiple connections are
concurrently handled by the same Apache process, so mod_jk can
efficiently reuse its backend connections for requests from other
connections handled by the same process. The total used connection pool
size might then be much smaller than with the prefork MPM.



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

View raw message