JBoss Farming and exploded ears

[modoc]

We?re looking at migrating to Jboss for our main cluster (100+ instances), and would like to explore adding support for exploded archives to the farming deployment system. I understand the issues around that, such as incomplete deployments being replicated, but I?d like to discuss the level of difficulty in setting that up, possibly keying a special file (complete.txt) or off of a JMS event, to signal a completed deployment?

The ability to push only updated files (based on timestamp or hash) as part of that would be nice as well, from an efficiency point of view. Our current .ear is 1 GB and growing, and the changes are usually limited to a few files.

Thoughts?

Thanks!

Modoc

[brian.stansberry]

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!

[modoc]

Brian,

thanks for the reply. Lots of good info for me in there.

Is this something that you guys (JBoss) are looking at? Or am I the only one who wants this sort of thing?

i.e. is this a potential future enhancement, or would I be on my own to implement this for our use?

Thanks!

Modoc

[brian.stansberry]

This isn't something that's on our short to medium term roadmap. If you developed and contributed it, I'd help you out as I could and if it works out we could add it to the JBoss code base and maintain it.