Hi Chris,
On 03.03.2009 17:22, Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Rainer,
On 3/2/2009 11:07 AM, Rainer Jung wrote:
I think a robust implementation 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
Just to be clear, you are talking about a new feature that would
temporarily adjust the setting for the "activation" property of a
particular worker in a load-balanced configuration, right? This would
take a worker from activation=Active to activation=D in response to some
"configurable probe request" that would be sent by the watchdog thread
periodically. Presumably, the application would eventually respond with
"re-enable this worker".
Exactly.
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?
I tend to agree with Rainer, here: if you put a cap on your sessions
(per app server) and you are worried about hitting that limit, then you
are likely to hit that limit on all your servers eventually. What, then?
Show a "too many sessions; come back later" page?
I suppose this could be useful for peak-load scenarios where you want to
try as hard as possible to max-out the number of sessions available /in
the cluster/ and not turn anyone away from a particular app server
(which would be easy enough to do simply by counting active sessions and
throwing an exception when the limit is reached).
That's why I think it is not a high priority feature. Saving
configuration changes done via the status worker, rotating log files for
IIS, and a couple of others seem to have a higher importance.
But of course, if someone writes a patch ...
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
