tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <>
Subject Re: disable behaviour for a worker in modjk
Date Mon, 19 Jan 2009 18:58:11 GMT
On 19.01.2009 13:40, wrote:
> Hi
> We are interested to know what the exact behaviour of modjk is with
> regards to current running requests when you disable a worker in the web
> interface. Does it drop all requests currently being processed by that
> worker or would it wait for requests to be finalized? The worker is part
> of a load balancer group of servers.
> We believe that to disable a worker in modjk (part of a loadbalancer
> group) before undeploying/deploying an application in tomcat is a
> cleaner method than relying on modjk to pickup unavailability of the
> application.

Activation state, i.e. active, disabled or stopped is only relevant when 
a request comes in and mod_jk needs to decide to which backend it should 
forward it. Once a request has gone through that, a change in worker 
activation will not change its processing.

So, yes it is a cleaner method, e.g. because you don't get an error in 
your log and thus you can take *all* your errors in the logs serious and 
do not have to remember when you had expected errors, because you 
stopped workers.

Remember: disable will still allow to forward requests to the worker, 
namely when the session cookie or the URL encoded session id indicate, 
that the session of the request is kept on the Tomcat instance of the 

So "disable" is used to drain a worker (no new sesions, so depending on 
your typical session use time the number of sesions will go down close 
to 0 in minutes or hours), to prepare maintenance.

"stop" is the state to use, when you are really shutting down a worker, 
because then mod_jk knows, that it shouldn't send any requests to it. 
The statement in the first paragraph also holds true for "stopped".



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message