In mod-jk, we had the ability to disable and/or stop a worker. Disabling a wroker W meant that existing sessions would be served, but new sessions would not be created on W, until W was enabled again. I'd like to have the same capability in mod-cluster. It would be good to have * this capability added to /mod_cluster-manager and possibly * provide a script (in jboss/bin ?) which allows an admin to do the same thing, e.g. "./disable-worker.sh node2" or "./disable-domain D3"

The functionality should include * Disabling a worker W * Stopping a worker W. Note that we can achieve this by shutting W down, but 'stopping a worker' merely removes W from httpd's worker list, but doesn't require a shutdown of W (W would also not register with httpd at this point) * Starting a worker W. The opposite of stopping W. Have W resume registering with httpd * Enabling a worker W. Allows for new sessions to be created on W

* Disabling / stopping / starting / enabling a domain D. Same as above, but for all workers in a given domain D. * It would be nice to be notified when all sessions in a disabled domain have expired

Can we create a JIRA to do this ?

jean-frederic clere wrote: > Bela Ban wrote: >> In mod-jk, we had the ability to disable and/or stop a worker. >> Disabling a wroker W meant that existing sessions would be served, >> but new sessions would not be created on W, until W was enabled again. >> >> I'd like to have the same capability in mod-cluster. It would be good >> to have >> >> * this capability added to /mod_cluster-manager and possibly >> * provide a script (in jboss/bin ?) which allows an admin to do the >> same thing, e.g. "./disable-worker.sh node2" or >> "./disable-domain D3" > > If you look to http://www.jboss.org/community/docs/DOC-11425 we > already have the messages for that the -APP command with wildcard are > for all the contexts of the node. Yes, I know. But we need a drive which generates these messages, e.g. a script.

>> >> The functionality should include >> >> * Disabling a worker W >> * Stopping a worker W. Note that we can achieve this by shutting W >> down, but 'stopping a worker' merely removes W from httpd's worker >> list, but doesn't require a shutdown of W (W would also not >> register with httpd at this point) >> * Starting a worker W. The opposite of stopping W. Have W resume >> registering with httpd >> * Enabling a worker W. Allows for new sessions to be created on W > > > Of course any of those action would be overwritten in case a CONFIG > message or a -APP command with wild card is received from the cluster Yes >> * Disabling / stopping / starting / enabling a domain D. Same as >> above, but for all workers in a given domain D. >> * It would be nice to be notified when all sessions in a disabled >> domain have expired > > That something which is not the MCM protocol, how should we handle a > CONFIG or any message from the cluster that affects a node belonging > to the domain? The last point is food for thought. But it is very important IMO to have the ability to disable an entire domain D, ie. not create any new sessions on any node in D. When all sessions in all nodes in D have expired, then we can shut down all nodes in D and upgrade them and later start them again. > >> >> Can we create a JIRA to do this ? >> > > Well I think we should discuss on the dev-list before. That's what we're doing here isn't it ? :-)