-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, just googled what you're after and bumped to: http://www.lowth.com/cutter/ HTH P.S. Our Sonicwall devices have that feature to close established connections when they hit a predefined timeout value with no data passing through. - -Nik On 11/25/2011 03:45 PM, lu zhongda wrote: > Hi Brian: > We supply java application server product to our customer. > The application server supplies jdbc connection pool functionality to deployed web application. > The jdbc connection pool usually keeps a fixed count of physical connections to database which are socket connections. > The support staff reflected that the connections in the connection pool were dropped by firewall after 30mins to > become idle under customer environment . > I can't get clear information whether the firewall product is iptables. > > I googled the topic "firewall drop idle connection" on the Internet, found somebody met the same issue like me even > though they used the firewall product of cisco > such as: > http://vivekagarwal.wordpress.com/2009/07/04/firewall-dropping-oracle-database-connections-in-websphere-connection-pool/ > > Even some web page indicated that iptables can drop idle connection, such as the tcp section of > > http://www.rigacci.org/wiki/lib/exe/fetch.php/doc/appunti/linux/sa/iptables/conntrack.html > > > I am familiar with Linux, so i want to reproduce the issue with iptables, this is why i posed this topic, I want to > know whether iptables support this or not. > If yes, what is the detailed rule set, if not then that is. > > As to whether iptables should support this feature, it seems that some product supported this, such as pfsense on > freebsd or some commercial product. > Because I never touch freebsd, so I don't want to use pfsense . From my opinion closing the idle connection can > avoid the upper application leak idle connection, > releasing unused system socket resource. So it is a useful feature if iptables can support this. > > This is the background for my question and is my real-world use case, haw-haw. > Thanks for your help and hope for your answer. > > On 2011-11-25 19:16, Brian J. Murrell wrote: >> On 11-11-25 12:37 AM, lu zhongda wrote: >>> On 2011-11-24 19:30, Brian J. Murrell wrote: >>>> You didn't answer my other question though, which is why do you think >>>> you need to be dropping idle, yet still ESTABLISHED sessions (and >>>> breaking higher level protocols when you do that)? >>> The need to drop idle connection comes from one technical support request: >> Answering my question of "why do you want to do this" with "because >> somebody asked" does not really answer the question though. >> >> There is an important reason for me to to ask and you to answer the >> question (i.e. with a real-world use-case) and that's because typically >> when somebody is proposing to do things that are "strange" or "not as >> intended" (and indeed which will result in other things breaking -- like >> TCP in this case) it's because they are trying to solve a problem with >> the wrong tool. >> >> Can you please provide a real-world use-case as to why you'd want/need >> to stop (i.e. break) an open TCP session? >> >> Cheers, >> b. >> > > -- > To unsubscribe from this list: send the line "unsubscribe netfilter" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOz6QfAAoJEDFLYVOGGjgXuiIIAOPlQpEkbvo3l2CFPOZ8Y1P3 DIqWsBsImFwGq3/xAk8Poypsz3ZLN+dzsGdGmBHVVF8mzTJO4bn33yEmIYj7wXPC +8zuKHBiXXXrguS/nZq3Xr19KoWGTDvBa/HanO3q5uq7mJaMETo484jf2uHYZbCS ms4pd0BvKGGMhu5r781hcRdUU2ZXmsm8LmVyfKYDUkGrgLqQrJGrcs+s6KMDe89p vU+/6rdXnDfVjhIasKZshuiwTbhTcKEULpVot+oiJLQ5uT7ova4yXL6AP626wO4c FHfeK8RfBImQLgDRWOx5GPcdEPFt06sBwPEcJJUdcleW8Vy5xYiUFAZZSpFFIhY= =LG4G -----END PGP SIGNATURE----- -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
