I still don't have a consistent idea what happened around the firewall: - silently dropping is not expected apart from a deny rule, but deny will not be the rule that had been applied to the apache-tomcat connection.
- only shutting down one side of an established (!) connection seems broken - no answers yet about using TCP keep-alive - 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 I would find out, whether it's easy to do over the weekend, but I would like to get some feedback on the idea. - Anyone who can reproduce a real problem, when mod_jk shuts down a connection? I reported, that with a recent mod_jk and TC 5.5.17 on Solaris it's not a problem, and the TC code and the Java API doc suggest it's no problem on any platform. Regards Rainer Filip Hanik - Dev Lists schrieb: > Rainer Jung wrote: >> 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). >> > definitely not a broken firewall, works exactly like it should. it > silently drops, that is how it avoids making itself vulnerable to DOS >> 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] >> >> >> > > > --------------------------------------------------------------------- > 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]
