Just wanted to point out that on #1 below: many real world environments have web servers in a DMZ and a firewall between their web servers an app servers. The default assumption should be that AJP connections can and are frequently broken. Firewalls will do this to you.
I'm curious why tomcat and mod_jk both won't detect properly closed sockets out of the box? I can understand why firewall disconnects would go unnoticed, but if you set cache_timeout, recycle_timeout, or MaxRequestsPerClient, I'd expect the TCP connection to notify the other end of the close and for the app server to detect it like any well behaved TCP-based server. There are many ways to detect the properly closed socket- some event-based ways as well, both in a C and Java. It seems odd that we'd need to set a timeout to wake up a server to cleanup properly closed sockets- that should be inherent to its operation. Byron -----Original Message----- From: Mladen Turk [mailto:[EMAIL PROTECTED] Sent: Friday, January 20, 2006 5:19 AM To: Tomcat Users List Subject: Re: mod_jk connection problem after couple of days or a week Jonathon Reeve wrote: > Well I'm glad someone else is getting this, even if you have no idea > either. We wondered if we were missing some configuration from > workers.properties, since the "quick start" section > (http://tomcat.apache.org/connectors-doc/howto/quick.html) on Tomcat's > site gives an example "minimum workers.properties": > Huh, you really tried everything :) Couple of notes: 1. AJP connection is supposed to last forever. 2. cache_timeout, recycle_timeout, MaxRequestsPerClient tend to close the socket, so you have half-closed sockets, and that's why you are leaking resources. 3. Whenever there is a need to recycle one end of the channel the other end must be recycled too. This is done by setting connectionTimeout="milliseconds" in server.xml for AJP/1.3 connector. 4. If you need full failover add 'connection_timeout' and 'prepost_timeout' to each worker. This implicates that CPING/CPONG packets will be send before each request is forwarded to Tomcat. Regards, Mladen. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
