https://issues.apache.org/bugzilla/show_bug.cgi?id=46808
--- Comment #6 from Eiji Takahashi <mashm...@gmail.com> 2009-03-07 07:28:41 PST --- Hi. I'm sorry that the explanation is insufficient. I used the roughly following settings. ----- worker.list=wlb # not use socket_connect_timeout worker.ap00.socket_timeout=5 worker.ap00.prepost_timeout=3000 worker.ap00.connect_timeout=3000 # not use max_reply_timeouts worker.ap00.reply_timeout=310000 worker.ap00.recovery_options=3 worker.ap01.reference=ap00 worker.ap02.reference=ap00 worker.wlb.sticky_session=True worker.wlb.sticky_session_force=False worker.wlb.balance_workers=ap01, ap02 worker.wlb.method=B --- Please look at the attached log about an actual situation. - The NW cable has been pulled out around 13:35:47. - The request that has ap01 as route tried to connect to ap01, and failed to connect. And ap01 was in local error state (not error state). - Ap01 had become in error state (not local error state) at 13:50:06. It seems that it is because all sessionid with ap01 as a route ended. When the NW cable on the ap01 side is pulled out, the request that has been transmitted to Tomcat returns error to the client because of recovery_options is set to 3. I think that this is not a problem. However, when the state of lbworker doesn't become JK_LB_STATE_ERROR, the request that has ap01 as route in the sessionid tries to connect to ap01. And keeps trying to connect to ap01 until sessionid become invalid. I think that this is a problem, because "socket_timeout * retries" ( equals 10secs in my case ) is added to the request processing time without fail. When the request that don't have sessionid connects to ap01, the time for the connection is wasted. I think this is a problem, too. However, because the failover occurs, the request is forwarded to ap02 and sessionid is given in ap02. As a result, the next time of this request is not transmitted to ap01. Best regards. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
