Hey Mladen,
I have made successfull a test implementation to deactived a worker. I works very fine for me at windows.
Now made a second test under apache 2.0.54 and Linux 9.3 with worker and prefork MPM.
I think in two hour I am ready to checkin the change. :-)
Peter
Peter Rossbach schrieb:
Hey Mladen,
Mladen Turk schrieb:
Peter Rossbach wrote:
Hey Mladen,
I used the tomcat at cluster mode, but your answer is a little bit to easy.
Sticky session is the only way for the most applications to be consistens.
Session replication is only a secondary feature when failure occured.
Why we can't add a flag that deactive a worker or change the semantic of disable?
Then all request goes to the other replication members in a cluster domain and restarting
is easy without risk and waiting time.
Are you sure this is absolute necessity?
YES! We monitor the cluster and when one member is not accessiable or
throw Out of memory Exception, the node was automaticly restart. Also
this mode is fine for minor node or application configuration update.
It is not usefull for complete new deployment, when serialized classes changed :-)
Hmm, but the fallback server (same cluster domain) has the sessions at this moment and the user see nothing from the switch.I agree something like that might be usable on a development server, but on a production server? I'm not sure if your users will be happy with loosing sessions in a middle of a transaction or order.
This suggestion is the result of my last two week pre production tests and customer discussions.
Again, disable works as expected. It will preserve exiting sessions until session times out. When all existing sessions are gone, then you can do with that node what ever you wish. If you do not wish to wait, then simply disable and kill that instance. The existing sessions will be failovered to another node with loosing session data.
But at cluster the session are replicated, and we must not wait. Please, can we
add a flag active=false/true to test my idea. What do you thing I can start
a quick experiment and send you the diffs for reviewing?
I see no reason whatsoever for introducing another 'immediate disable' flag to the worker.
I hope my description help do understand my suggestion better.
Regards, Mladeb.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
