Re: JK Connector SYN packet for established connection
Antonio Fiol Bonnín wrote, On 3/11/2004 11:11 PM: Tomcat will detect the closed connection and return that JK thread back to the pool for later use. It won't. If the firewall has already dropped the connection, Tomcat will not notice it being closed. OK, so if the conn is dropped, TC won't know what to do with it as it will sit there and wait forever for input. I can't find any options in the JK connectors to change the behavior of the server... The easy solution should be to add an option to enable keep alive on the server side as well. And as I said (and sources seem to agree with me ;-), socket_timeout is only checked synchronously, i.e. at usage time. So, maybe socket_timeout=10, but you may have connections staying up for ... as long as a whole night of deep inactivity. Good point, I did not think of that. In the morning, if you netstat on both machines, you will see a different number of ESTABLISHED connections. You will have more of them in the Tomcat side. And that is not good. Add up some nights, and you will have to restart your tomcat server in a couple of days / a week / a couple of weeks, depending on your MaxSpareClients (or equivalent) in your web server and your maxProcessors / maxThreads in Tomcat. Yeah, that's not good. Although it's better than having the server get stuck after only a few minutes of idle time. ;-) -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JK Connector SYN packet for established connection
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? Thanks, Pat. -Original Message- From: David Rees [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 10, 2004 9:47 AM To: Tomcat Users List Subject: Re: JK Connector SYN packet for established connection CONANT,PATRICK (HP-FtCollins,ex1) wrote, On 3/10/2004 7:58 AM: Our workers.properties file is pretty simple: worker.list=frontend worker.frontend.host=X.XXX.hp.com worker.frontend.type=ajp13 worker.frontend.port=8007 Try setting the socket_keepalive and socket_timeout options and see if that helps: worker.frontend.socket_keepalive=1 worker.frontend.socket_timeout=300 -Dave - 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]
RE: JK Connector SYN packet for established connection
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]
Re: JK Connector SYN packet for established connection
That won't help. 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
Re: JK Connector SYN packet for established connection
Antonio Fiol Bonnín wrote: That won't help. I think it will, see below. 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. Why will it cause problems on the Tomcat side? IMO, it has a good chance of fixing the problem as Apache/mod_jk will open a new connection if it hasn't been used for a while which should prevent the SYN problem the original poster was having problems with. Tomcat will detect the closed connection and return that JK thread back to the pool for later use. Even if it doesn't help, it's an easy change to try. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK Connector SYN packet for established connection
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. Why will it cause problems on the Tomcat side? See below. IMO, it has a good chance of fixing the problem as Apache/mod_jk will open a new connection if it hasn't been used for a while which should prevent the SYN problem the original poster was having problems with. It's worth trying. Agreed. Tomcat will detect the closed connection and return that JK thread back to the pool for later use. It won't. If the firewall has already dropped the connection, Tomcat will not notice it being closed. And as I said (and sources seem to agree with me ;-), socket_timeout is only checked synchronously, i.e. at usage time. So, maybe socket_timeout=10, but you may have connections staying up for ... as long as a whole night of deep inactivity. In the morning, if you netstat on both machines, you will see a different number of ESTABLISHED connections. You will have more of them in the Tomcat side. And that is not good. Add up some nights, and you will have to restart your tomcat server in a couple of days / a week / a couple of weeks, depending on your MaxSpareClients (or equivalent) in your web server and your maxProcessors / maxThreads in Tomcat. That is because Tomcat does not use keepalive on its side, and never sends any data to the client if the data has not been requested (AFAIK). Some time ago, I proposed to fix this. I am not sure what the conclusion was. Even if it doesn't help, it's an easy change to try. Agreed. -Dave Antonio Fiol smime.p7s Description: S/MIME Cryptographic Signature
Re: JK Connector SYN packet for established connection
CONANT,PATRICK (HP-FtCollins,ex1) wrote, On 3/10/2004 7:58 AM: Our workers.properties file is pretty simple: worker.list=frontend worker.frontend.host=X.XXX.hp.com worker.frontend.type=ajp13 worker.frontend.port=8007 Try setting the socket_keepalive and socket_timeout options and see if that helps: worker.frontend.socket_keepalive=1 worker.frontend.socket_timeout=300 -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
