tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <rainer.j...@kippdata.de>
Subject Re: mod_jk replacement?
Date Tue, 23 Jan 2007 19:53:17 GMT
OK, one small error or typo in communication:

connection timeout on mod_jk side is in seconds, on tomcat side is in
milliseconds. So Mladens suggestion had a missing trailing 0 to make the
params on the two sides fit. I think he meant connectionTimeout=600000
to make it fit the 600 on the mod_jk side.

Then: on the tomcat side the timeout is realized exactly, i.e. if the
timeout is being triggered, tomcat closes the connection and frees the
thread. On the mod_jk side, the connections are checked every now and
then to find the ones which are idle longer than the timeout. "Every now
and then" more precisely means, that whenever a request gets handled,
mod_jk checks, if the last so called maintenance happened at least 60
seconds ago. If yes it calls another round of maintenance, which will
check all connections for their idle timeouts.

I still don't understand your err=-53, that's a value I never expected
with customers. If you can easily reproduce, a mod_jk log with
JkLogLevel debug would be helpful.

Another thing: closing the connections is not directly related to the
thread pool size on the tomcat side. The docs page
http://tomcat.apache.org/tomcat-5.5-doc/config/ajp.html contains the
parameters to define, e.g. how many idle threads will be kept in the
pool. Using ajp13, a thread will be busy from the tomcat thread pool
view, whenever it is connected to apache, and idle, if there is no such
connection. This differs from a more naive view of busy=request. So if
you only wonder why there are still 27 threads on the tomcat side:
that's OK for your config. If you think there are still 27 busy tomcat
threads: then please provide two java thread dumps for tomcat after your
"rapid click test" (wait a few seconds betwenn dumping) and then another
one or two after the 600 seconds passed by.

Finally: from your last statement I'm not sure that I understand, what
the real problems are now:

Memory Leak: there was no memory leak, but you noticed, that your
apache/mod_jk needed more memory than you expected (the 70MB) and the
memory didn't get freed, after the connections have been closed (I
wouldn't have expected such a free). My comment: it's not a leak
(meaning a steady increase of memory over time without a reasonable
upper limit), and I still don't think, that 70MB is that much, so that
it would be necessary to do research here.

Connection close: not sure, if everything is clear now.

Thread count: see explanation above.

Service state, after your rapid click test: your last sentences sound,
as if the service still works after this test.

mod_jk error 53: the only remaining problem. Does it imply a problem on
the user side?

Regards,

Rainer

JNeuhoff schrieb:
>> Whenever you have connection pool setup 
>> in mod_jk it means you don't have constant connections 
>> any more. The connection pool will maintain the 
>> connections and close them by some rule (size). 
>> Now, having that you *must* have connectionTimeout="60000" 
>> in server.xml for the AJP connector so Tomcat can close 
>> his part of the connection as well.
> 
> I see. I added the connectionTimeout="60000" as suggested, using now
> 
>     <!-- Define an AJP 1.3 Connector on port 8009 -->
>     <Connector port="8009"
>                enableLookups="false" redirectPort="8443" protocol="AJP/1.3"
> connectionTimeout="60000"/>
> 
> 
> in my server.xml, everything else is still the same. We then subjected our
> webserver to 2 users who were rapidly clicking on web links within our site
> for a few minutes, about twice as fast as the service could respond. Tomcat
> now reports a Current thread count: 27 , and it coesn't come down after the
> connection_pool_timeout=600 (10 minutes) to the expected
> connection_pool_minsize=10 TCP connections (= number of remaining minimum
> threads?). The maximum number of HTTP Sessions was 10 according to our
> session listener. The web service still receives requests and responds
> normally, yet mod_jk now always comes up with this in its mod_jk.log:
> 
> .....
> [Tue Jan 23 17:56:42 2007] [0436:2428] [error] jk_ajp_common.c (948):
> (ajp13) can't receive the response message from tomcat, network problems or
> tomcat is down (127.0.0.1:8009), err=-53
> [Tue Jan 23 17:56:42 2007] [0436:2428] [error] jk_ajp_common.c (1566):
> (ajp13) Tomcat is down or refused connection. No response has been sent to
> the client (yet)
> [Tue Jan 23 17:56:42 2007] [0436:2428] [info]  jk_ajp_common.c (1877):
> (ajp13) receiving from tomcat failed, recoverable operation attempt=0
> [Tue Jan 23 17:56:42 2007] [0436:2428] [info]  jk_ajp_common.c (1916):
> (ajp13) sending request to tomcat failed,  recoverable operation attempt=1
> [Tue Jan 23 17:56:42 2007] [0436:2428] [error] jk_ajp_common.c (948):
> (ajp13) can't receive the response message from tomcat, network problems or
> tomcat is down (127.0.0.1:8009), err=-53
> [Tue Jan 23 17:56:42 2007] [0436:2428] [error] jk_ajp_common.c (1566):
> (ajp13) Tomcat is down or refused connection. No response has been sent to
> the client (yet)
> [Tue Jan 23 17:56:42 2007] [0436:2428] [info]  jk_ajp_common.c (1877):
> (ajp13) receiving from tomcat failed, recoverable operation attempt=1
> [Tue Jan 23 17:56:42 2007] [0436:2428] [info]  jk_ajp_common.c (1916):
> (ajp13) sending request to tomcat failed,  recoverable operation attempt=2
> [Tue Jan 23 17:56:42 2007] [0436:2428] [error] jk_ajp_common.c (1928):
> (ajp13) Connecting to tomcat failed. Tomcat is probably not started or is
> listening on the wrong port
> [Tue Jan 23 17:56:42 2007] ajp13 daohprw2 0.296977 GET /ohpr/servlet/
> HTTP/1.1 200
> [Tue Jan 23 17:56:42 2007] [0436:2428] [info]  mod_jk.c (2142): Service
> error=0 for worker=ajp13
> .....
> 
> 
> So it looks like the connection pool doesn't recover for some unkown
> reasons. Is there anything else I have missed out on? Not restarting the
> Apache2 and Tomcat NT services clears up this stalemate scenario, only a
> complete server reboot does it.
> 
> J.Neuhoff
> 

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message