Jim Jagielski schrieb: > In a nutshell, there are many cases where Apache httpd and > Tomcat are separated by a firewall, and, as such, there > isn't a one-to-one direct connection. The firewall > will close a connection but one side doesn't > know about it.
I would call this a broken firewall, right? This kind of behaviour is expected to produce problems for nearl every communication (I don't say, we shouldn't provide a workaround). Still: do you know, what happened in the actual problem case: - which side of the communication has been shut down by the firewall, Apache-FW or FW-Tomcat? - did it reset it, do a full Fin-Ack... or did it just start to silently drop packets? - was keep_alive anbled for the worker? This is a standard socket option, that is used to simulate traffic on a connection. The default settings for many OSes are interval equals 7200 seconds, so that only onc every 2 hours a TCP keep alive packet is being sent. Depending on the FW admins idea about idleness, it might be enough to simply lower the keep alive interval in the OS TCP configuration. Has this been tried? > As such, new requests create more > sockets until TC runs out of threads. mod_jk is > not recycling connections as it should, and What do you mean by "not recycling"? I think this symptom hasn't been reported until now. > setting the various params (eg: connection_pool_timeout) > does not solve the problem. It's similar to the old > Apache http lingering close problem. > > http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg75444.html > is one example of such problems, in which case you > responded and agreed that don't reuse is a last resort > solution. I don't find lingering close in this message. The primary situation for this user was the need to connect a lot of Apache threads to a tomcat. In the meantim the APR connector got more stable, so that would be the best choice for him. If he will still run out of threads on the tomcat side, he will need to segment his setup into smaller cells. Trying to "solve" this kind of situation by not reusing connections is really no solution, but a broken system design. > I just think it would be nice to provide that last > resort :) With this I agree. There is another possible solution: we could add another parameter to the pool sizing, the max idle count. This would be exactly analogous to the httpd and tomcat pool semantics. Setting it to 0 would mean, that no connection will be put back into the pool and instead all connections are being closed after a request. Comments? > --------------------------------------------------------------------- > 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]
