tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <>
Subject Re: Jk disable worker on status
Date Mon, 02 Mar 2009 16:07:54 GMT
On 02.03.2009 15:55, mturra wrote:
> I have a tomcat farm behind an apache httpd cluster, each apache http server
> have a jk connector connected to three tomcat.
> Each tomcat have a max active session limit (let's say 10).
> I configured a load balanced worker with three worker.
> I would like to disable the worker related to the tomcat server that reach
> the max active session limit.

Altgough we try to distribute new sessions equally between nodes, we 
don't actually know how many sessions each node has.

We simply count requests which do not carry any session information as 
"new sessions", and we divide the new sessions counter of each node by 2 
once a minute.

We don't get any invalidation information from the backend, neither do 
we know, whether a request carrying a session id actually belongs to a 
valid session.

So we do not have any immediate way of limiting by session count.

> I see the fail_on_status directive in jk doc
> ( I can use
> it to deactivate (stop) the worker on a status code, but all the previous
> session on this tomcat will get an error and they will be redirected on
> another worker loosing session data (sticky session is required by
> application).
> There is no disable_on_status directive or something that exclude a worker
> only for request requiring new session?

No, there is not. We could provide one, but it would only make sense, if 
the webapp would provide us with a special indication, that the node 
should be disabled. So you would need a filter, that checks the number 
of sessions, and if it is over the limit, the filter would return the 
indication. But since we already send the request to the node, in some 
cases, like e.g. POST requests, we cannot make sure, that we can send 
the same request to some other node.

Furthermore, disabled is a configuration state. You do not only want it 
to be set automatically, but you also need a way of revoking it later.

I think a robust implemenation would be something like:

- a new state for temporarily disabling a node, except for sticky requests

- a configurable probe request, that the watchdog thread sends, and 
which is answered by the application, the answer containing the 
information whether the node should be temporarily disabled or not

Beware, that the watchdog thread would only probe e.g. once a minute, so 
some requests might still be send to the backend, although the limit has 
been reached.

I'm not sure, what the purpose of this is. Assume our session load 
balancing works, so that all three nodes have an equal number of 
sessions, you would soon end up having all your nodes temporarily 
disabled. No?



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

View raw message