Hi Mladen, Mladen Turk schrieb: > Rainer Jung wrote: >> I still don't have a consistent idea what happened around the firewall: >> > > It is a very simple:
I don't think so, because no one was able to give the details. From a "simple" perspective everything is clear, but only the details will give an indication, what the correct way to respond is. See the mail by Klaus Wagner and my response. > 1. There are firewalls that will cut the connection > between mod_jk and Tomcat without sending FIN. > You can not do anything with that, cause they > simply exist, and I don't care why they exist. I don't care too, but the fact, that they don't send a FIN is important. Thanks. > 2. Only the Tomcat is affected cause mod_jk connects > to it. With mod_jk if write() fails we reconnect, > but Tomcat still waits on stream read() and > disconnects on some systems after 240 secs, > thus rising the thread count. Correct, in that case, no one shut down the connection. In case the correction shuts down cleanly, I found no indication, that this will still cause a problem on the tomcat side. > 3. Up to 1.2.18 even the httpd restart could cause > thread count to double in size. OK, late thanks for your fix! > So, having that, the only solution is to: 0. Configure your TCP stack according to the idle timeout restrictions your network admins place on your network environment (TCP keepalive interval) or > 1. Set connectionTimeout in Tomcat that will always > close the inactive connections > 2. Use CPING/CPONG to detect disconnected sockets > prior sending request. > Now, the advanced thing should set the reuse flag to > false according to the maxKeepAliveRequests in returned > AJP packet. This will cause both Keep-Alive to work > and graceful socket disconnection because both sides > will be closed. > >> - no comments on my suggestion to make the connection pool more >> flexible: min pool size, max pool size and max connection number? this >> will allow us to >> >> - temporarily connect although the pool is expired with a defined limit >> - configure for not reusing connections by setting max_idle to 0 >> > > We have that already in 1.2.18. No: I'm talking about max_idle, min_idle and max_connection. We have connection_pool_size and conection_pool_minsize. They map as follows: Compatibility situation: min_idle=connection_pool_minsize max_idle=max_connection=connection_pool_maxsize But by giving max_connection a bigger value than max_idle, we would allow additional connections in case the pool is exhausted, which will not be pooled after end of their usage. A special case would be minIdle=max_idle=0 and max_connection=num_of_threads, which will lead to unpooled connections, i.e. each connection will be destroyed after use. The model is totally analogous to the httpd process model (maximum processes and min and max spare processes) and to the tomcat thread model for connection pools and thus should sound familiar to the users. The connctions in the pool are those that are counted as idle. > > Regards, > Mladen. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
