This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
The moose likes Tomcat and the fly likes understanding keepAliveTimeout timeout Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Products » Tomcat
Bookmark "understanding keepAliveTimeout timeout " Watch "understanding keepAliveTimeout timeout " New topic
Author

understanding keepAliveTimeout timeout

adam spline
Greenhorn

Joined: Sep 29, 2010
Posts: 18
Hi all,

I am just writing to make sure that I understand how the keepAliveTimeout works in Tomcat.

I am using Tomcat 7. The client (which happens to be a sliverlight app) polls the server every few seconds for new data. Since, it is every few second is below the keepAliveTimeout, I assume that it keeping the connection alive on the server, and thus will not have to renegotiate TCP. I installed an app to view the http headers, it does look like keep alive is one, along with content lengths. Would I see something in the http headers if it was closing the connection somewhere?

According to the tomcat docs, it appears that the default for the keepAliveTimeout is set to the connectionTimeout (which is 60 secs). So, as I understand it, the server will keep that TCP connection open with the client for 60 secs (so long as the client does not send a close request). Right?

If the number of threads is getting too high, does tomcat first close out these open connections before rejecting new connections?

We will likely be changing our model soon to Comet, but I just want to make sure I understand this portion.

Thanks,

-Adam
 
jQuery in Action, 2nd edition
 
subject: understanding keepAliveTimeout timeout
 
Similar Threads
Firewall timing out connections in Pool - Commons DBCP
Long running request returns no HTTP response
Type 4 driver connections
Real world network delay problem
Tomcat Sockets handling