On 12.01.2011 00:59, Andy Wang wrote:
I'm not sure, but it looks like the service() function in jk_lb_worker.c calls puts a recovering worker into the JK_LB_STATE_PROBE state and then doesn't set it to JK_LB_STATE_OK until after the end->service() call.I think this allows a second thread to come in, and since JK_WORKER_USABLE() returns false because of the JK_LB_STATE_PROBE state it never tries to use that worker and the second request thread completes, then the first request completes and finally marks the worker as JK_LB_STATE_OK. Still working on a reproducible state to debug this in, but does this sound like a possible problem or am I mis-reading what the end->service() call does here: service_stat = end->service(end, s, l,&is_service_error);
That was meant as an improvement. "Recovery" is only used, when a worker has been in error state for enough time (by default 60 seconds) and we want to find out whether it is still in error or not. mod_jk has no active probing with test URLs, so if the 60 seconds passed it marks the worker/instance a recoverable. Then it waits for the next request which is eligible to be handled by that instance (either carrying an old session iformation pointing to that instance or being freely balancable), and sends it there, marking the worker as being probed. If it succeeds, fine we can set the instance to OK. If not the instance goes back to error and the request will be sent to some other OK instance.
Most of the time an instance will be in error for longer time, so probing in parallel is not a good idea, e.g. if the error state leads to delays in request handling. OTOH if the worker is fine now, it should ususally respond very quickly, so the time window where request could have been handled by the worker but weren't is very small. This seems fine to me.
All this will be nicer once we add a probing feature to the maintenance thread which will probe the erroneous workers via a background thread and recover the worker as soon as the probing succeeds.
Regards, Rainer --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
