David Rees schrieb: >> So in case the remote host is dead (i.e. it's not only Tomcat not >> answering or no Tomcat there), we have the problem, that TCP as a >> reliable problem tries hard to establish a connection with several >> resends of SYNs in increasing intervals, leading to long waiting times. > > So with connect_timeout set to 500, mod_jk won't give up on the > connection attempt after 500 ms have elapsed?
Not in general. It depends on which part of the connect needs long. For the TCP connect it will use the socket_timeout configured. For the following Cping/Cpong the connect_timeout. >> Mostly I agree, but I would set a timeout for athe connection pool. > > Perhaps the default configuration and docs could be updated to reflect > that instead of setting to zero? I normally use these settings on my > servers: > > socket_keepalive=1 > socket_timeout=300 > connection_pool_timeout=300 > connect_timeout=500 > prepost_timeout=500 We never changed the defaults out of compatibility considerations. Most of the timeouts didn't exist from the beginning and that's why they are unfortunately disabled by default. > I also normally set the worker maintain and lb worker recover_time to > something lower than the default as well so that mod_jk picks up > recovering workers more quickly. It would be nice if worker > maintenance could be done by a process other than the > processes/threads which also process requests! > > -Dave That on the TODO for the next major release, provisionary named JK3. We will use the APR libs as an infrastructure, so that we can easily use threads. One use case will be a management thread, that does the maintenance and concurrently monitors the backend status. No timeline for that yet. Regards, Rainer --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
