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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
