Proposal for new FarmMemberSingletonService ------------------------------------------- Key: JBCLUSTER-67 URL: https://jira.jboss.org/jira/browse/JBCLUSTER-67 Project: JBoss Clustering Issue Type: Feature Request Security Level: Public(Everyone can see) Affects Versions: Q4Y5 Environment: Jboss 4.0.3RC2 Reporter: Gabriele Garuglieri Assignee: Scott Marlow Priority: Minor Attachments: FarmMemberSingletonService-withSync.zip, FarmMemberSingletonService.zip Here is the proposal for a new service that behaves like FarmMemberService for the farming part, but deploys files only on one node of the cluster. It has the following features: 1- it is obtained extending org.jboss.ha.framework.server.FarmMemberService 2- since the hierarchy org.jboss.deployment.scanner.URLDeploymentScanner, org.jboss.ha.framework.server.FarmMemberService was not extendable without pratically duplicating all the scanner code or entering in an "if, if, if..." nightmare i thought to refactor both classes to allow easy extendability. 3- it is associated with org.jboss.ha.singleton.HASingletonController which controls the singleton activation in only one node of the cluster. 4- in the nodes where the singleton is stopped it simply farms files in the controlled directories keeping them up to date with the other nodes 5- in the node where the singleton is started it behaves exactly like FarmMemberService 6- the singleton is always started in the first started node (HASingletonController behaviour) 7- if the active node is stopped the singleton is activated in the next node in startup order 8- the singleton may be stopped by stopping its controller (from web console) without shutting down the server and will be automatically activated in the next node in startup order 9- when the singleton is stopped without shutting down the node it immediately undeploys all the files and keeps the farming function active, the files will be deployed in the next node where the singleton is started 10- if the singleton, stopped from console, is restarted in a node first in startup order than the node where the the service was restarted, it stops the service in the other node regaining its master status (HASingletonController behaviour) 11- while refactoring i introduced a small change in FarmMemberService behaviour: the scanner is now run before calling pullNewDeployments() so this method is now able to check if files are up to date with coordinator node avoiding to always transfer files even when they are the same as those in coordinator node. For the rest the behaviour of both URLDeploymentScanner and FarmMemberService is not changed 12- while testing i corrected a couple of problems in org.jboss.ha.framework.server.ClusterFileTransfer.push(): - the first is that the remotePushWriteFile procedure is always called and when the cluster has only one active node this mean a lot useless work for each deployed file, this is bad overhead for large files. I introduced a control so that the push() proceeds only if the cluster has at least two nodes - the second is a real bug, the input.close() is missing and this in Windows systems locks the deployed files not allowing any longer to overwrite or delete them until the server is closed I hope this is accepted, because i plan to use it in my production env and i'd like to see it in official release Gabriele