httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Smith <...@sanger.ac.uk>
Subject Re: [users@httpd] Apache losing its connection from Tomcat in few minutes
Date Tue, 06 Sep 2016 15:02:32 GMT


On 9/6/2016 3:55 PM, Christopher Schultz wrote:
> -----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.
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
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)

> 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.
Still reverting to mod_proxy will almost certainly make the 
configuration easier, the debugging easier, and resolve his other issue...


> 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@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>



-- 
 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@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org


Mime
View raw message