On 9/6/2016 3:55 PM, Christopher Schultz wrote:
The problem is that when the firewall session is terminated (for the firewall we use) then it behaves in an unusual way - in that both ends think the connection is open, but it isn't in fact open. This means that timeouts/pings fail (no idea why - nor do Oracle - or the firewall manufacturer) using mod_proxy (and database wrappers) we have a solution that gets round this by dropping connections before the server is likely to get in this state (unfortunately you can't easily do this with mod_jk or interestingly oracle!) We think the problem is actually to do with some nasty-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 James, On 9/4/16 5:16 AM, Dr James Smith wrote:You don't give enough information about the setup to solve any of your problems really. Are the apache/tomcat/cms on the same box or different We have seen big problems with mod_jk when there are firewalls involved (so much so we don't use it any more but use mod_proxy instead) - connections are severed by the firewall - you need to look up "tcp keep alive" settings for your connections - but even then that doesn't help - mod_jk doesn't handle this situation well... (ditto nginx, mod_fcgi etc none of them really handle any form of flakyness when it comes to network well)I've been using mod_jk for quite a few years (both with and without firewalls) and never had any problems. The trick is that you have you have configure it correctly, just like you'd have to properly-configure mod_proxy as well. mod_jk uses a permanent-connection to the backend, and you have to arrange to have those connections re-established if they drop. You want to pair the connection_pool_timeout in mod_jk (in sec) with the connectionTimeout in Tomcat (in ms) to make sure that both sides of the channel will hang up the phone after an appropriate interval. Use of CPING/CPONG can help ensure that the connection hasn't been dropped by the firewall.
pooling process going under the hood. Note ping fails in an unusual manner!Interestingly we actually appear to get better performance under mod_proxy that mod_jk
(although we have to use an extra hop to deal with load balancing)
Still reverting to mod_proxy will almost certainly make the configuration easier, the debugging easier, and resolve his other issue...I suspect that Jayaram's problem is either a mismatched pair of connection_pool_timeout/connectionTimeout settings, or a value that is less than the idle-timeout on the firewall.
Hope that helps, - -chris -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJXztjUAAoJEBzwKT+lPKRY8MwP/jA123QoWtrYgUSKoOF/8qy/ WPa32ZFhcM3zdpmT5+Im6z7yt7m/v8jGYugd1/hvCWFX2VSuqOAIdGxxwI2OC2eq KRWvOgS0PgIwVWvzt7qPp5wILXcmWq0u9OuaXEpgVjKS7AZjPBcsbgi/54n65zkn Ac3lRvSgodZzmNGR6sO+FoUgUF9QnVcXcYJhVJVEb7kzFRSfN32XsIGzB9Z4Q2I9 +WN1F57qcWQrWwsq0Sth+7+E8SnLEhcTuCqultun4tC8Klhh9D63FKMd5L1kgDfZ cxqvxNwxcJUiRzrPjnBd7x9+R3GJ4chUgfq4a8DCXQntkochJEOtgsjOszqjAsl9 3vY3SwDeenzMpd0fwJ8aAhOShWDUSx3BoqV5PmfbrVCNGGA4BH0GIk6kqF37sh6p lBGgW/DjBV8Qk0P4vkk7ieuzv/czMDcuCRgGAAdlHImu/Z9PaWGhckqy0o+35hRj TtCoTlzHPyeAGFaqpD7kkUnHqbduv9QokhLE7xgRGUtaqk0/u0xCpNex208sR2oG WIzBJbfgu5JeSzPXstNGZtvkNEZl+Y5NAvGcAM/2hhmjR405nilfyrSRl6XkH5Te j2Vn4sRfpMxFe6gwe8KOqVHLaRVJk06GNhUUPrF6haATV2sDEC4B7kTCQYSXt2Oe pWHH9rRs5IKKKRu7yeDK =z0xI -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
--The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE.
--------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|