-----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". > 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). - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmtWWMACgkQ9CaO5/Lv0PB+JACfUYFns4ij4y0P8wkjkcSdxLV+ XyAAn0ATErHVBTw+fXw0KhZeETB8B/dF =0ypU -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
