socket_timeout tells Apache to CLOSE connections that have been unused for that time, but only WHEN it needs it.
So that will cause problems on the Tomcat side.
What we did (but our problem was slightly different) was:
Set the tcp keepalive sysctl of the web server (it is a Linux box, look for the equivalent on Windows) to a value LOWER than the firewall's drop time (1800 was OK for us).
Set socket_timeout for the worker to some value. It does not matter much. In fact, it can be as high as you wish.
Set socket_keepalive for the worker to 1, to enable it.
And... Good luck!!
Antonio Fiol
David Rees wrote:
CONANT,PATRICK (HP-FtCollins,ex1) wrote:
Thanks for the proposal. We made the change, but to no avail. When the IIS server came back up, we saw the same problem start almost immediately.
The only other report of this problem I could find was for a different product (http://www.firewall-1.org/2002-04/msg00180.html). I don't think that the cause could be the same: with the amount of traffic we're seeing, the JK connections should just remain open. Regardless, our firewall admin refuses to change the tcptimeout (as suggested in the above link) due to potential impacts on other applications.
Any other ideas?
Could you try setting the socket_timeout to an even lower value? Say 30s instead of 300?
worker.frontend.socket_timeout=30
-Dave
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
smime.p7s
Description: S/MIME Cryptographic Signature
