From: garu <nu...@jb...> - 2005-05-23 15:02:35
|
What i did is simply to decouple the farming from the deployment. The FarmMemberSingletonService is itself a singleton, controlled by org.jboss.ha.singleton.HASingletonController class, that scan a specific directory, lets call it /farmSingleton. When the service is started it immediately activates the farming, ie it pulls the deployments from the other nodes and start the scanner. The scanner call an override scan() method that calls a farm() method that, mimicking the URLDeploymentScanner deploy(), puts into a farmedSet all the deployments units found in scanned dir so that subsequent scan run won't call again the farm() method unless something changes for the deployment unit files. This means that if i remove a file from the /farmSingleton directory in any node of the cluster, the scanner for that node will call unfarm() and the file is immediately unfarmed in all the nodes. If i add or replace a file in the /farmSingleton directory in any node of the cluster, the scanner for that node will call farm() and the file is immediately farmed in all the nodes. This for the farming part, for the deployment part, as i said before, this service is itself a singleton and the deploy is controlled by the service receiving startSingleton() call. When the singleton is started the scan() will always call super.scan() so that the normal deploy cycle is activated and HASingletonController ensures that this can happen on only one node at time. If someone tries to start the singleton from jmx console, it checks with its controller if this is master node and refuse to start if it is not. If someone stop the singleton, it checks with its controller if this is master node and if it is, it simply stop the deploy scan cycle, activating the farm scan without undeploying the applications. If it is not the master node (like if someone stopped its controller), it also undeploy the applications (it is assuming that another node is becoming master). There are two drawbacks of the thing. First is the behaviour of the master node algorithms in DistributedReplicantManagerImpl. It is biased by cluster nodes startup order and is not symmmetric, ie if i stop HASingletonController in the first started node because for whatever reason i need that it relinquishes its master status in favour of another node, unless i bring down the whole server, i cannot restart HASingletonController for FarmMemberSingletonService otherwise it will reclaim back the master node status, which may be is not what i want. Second i didn't found any way to efficiently extend FarmMemberService so i had to duplicate all the code in the new class. I still have to get rid of a couple of perplexities i have about start/stop cycle, then polish a bit the code and add some comments, then i'll post it. Does it sound twisted enough? Gabriele. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878752#3878752 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878752 |