[jboss-dev-forums] [Design of Clustering on JBoss (Clusters/JBoss)] - Re: JBoss Farming and exploded ears

[bstansberry@jboss.com]

Sorry for the slow response; finally freed up a bit.

Please have a look in the AS codebase, cluster module, classes org.jboss.ha.framework.server.FarmMemberService and ClusterFileTransfer. Discussion below is based on those classes; those are what you'd need to build off of.

The basic problem with exploded deployments in farming is that on all nodes in the cluster there is a thread that's looping and scanning the farm folder. If that thread detects a change of the deployment's standard descriptor file while you're in the middle of copying your new exploded deployment, the deploy/farm operation will begin prematurely. This is a problem with deployments in the deploy dir as well, but the latency added by copying files around the network makes this even more of an issue with farming.

Probably the simplest workaround for this is to add mbean operations to the farm service that allow you to stop/restart the background thread. With this approach, deploying via farm wouldn't be as simple as a simple copy to farm, but it could be done.  Process would be:

1) Invoke the new "stopScannerThread" operation.
2) Copy your updated deployment to farm.
3) Invoke the new "startScannerThread" operation.

Internally then,

4) deploy() method gets invoked.
5) before replicating files around cluster, deploy() executes a RPC call to the cluster to stopScannerThread
6) deploy() replicates files around the cluster
7) deploy() executes an RPC call to startScannerThread().

For ease of operation, steps 1-3 could probably be scripted using twiddle, or packaged into a custom ant task.  Any code that could invoke the stop/startScannerThread mbean operations would do.

As for replicating multiple files instead of just one, deploy()/undeploy() would need to be changed to walk the directory tree referenced by DeployURL and replicate all files.

To only replicate changed files, you'd need to maintain a map of file names to lastModified dates so you could do the comparison in the deploy() method.

Of course all this needs to be bulletproof so you don't accidentally permanently stop the scanner thread or break things in other ways I'm not thinking of!

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3987436#3987436

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3987436