Cold Deployment

[jleech]

I would like to do cold deployment rather than hot deployment for the following reasons:
1) Hot deployment deploys simultaneously to all the nodes, resulting in down time.
2) Hot (re)deployment of my application sometimes results in OutOfMemory errors.

The way I imagined it would work is I would have my application running on several nodes. I would stop one, deploy the new version to its farm directory, and start it back up. And repeat the process for the other nodes.

In reality what happens when I do that is that the new version of the application is not deployed anywhere, exactly as described in http://wiki.jboss.org/wiki/Wiki.jsp?page=JoinTheClusterBeforeUpdatingTheFarmDirectory

Is there a way to disable hot deployment, but still use all the other clustering features?

[ben.wang]

Maybe I am missing something here. If you want cold deployment, why do you need to deploy your app under farm directory? Shouldn't a regular deploy directory work the same?

[jleech]

Maybe I am missing something here. If you want cold deployment, why do you need to deploy your app under farm directory? Shouldn't a regular deploy directory work the same?

Perhaps... I am new to JBoss clustering and thought deploying to the farm directory might give special clustering powers to the EJBs in the application. Does deploying to the farm directory just do a distributed hot deployment?

[brian.stansberry]

Yes, just a distributed deployment. There is an issue that prevents placing something in a node that is not running and then having it deploy when the node starts.

[evk]

Hi, thanks for the information. I'm running into this issue as well. I have a cluster of several nodes and just want to be able to have nodes go down and come up at random and not have clients notice (assumption is that at least one node will be up at any given time)... as it is, in a simple two node cluster I've been testing on, if one node goes down and then comes back up, unless I manually trigger hot deployment somehow, coming back up will use cold deployment and that node will be useless since my app won't be loaded.

So I have two questions:

Is there a recommended best practice for deployment that can mitigate this issue? For example, would having each node point to a central HTTP farm URL help at all, since it might be easier to trigger hot deployment everywhere by updating the "last modified" time on the centrally-distributed file?

And is there any projected timetable for a fix of the underlying issue itself?

Thanks,
--Erik

[smarlow]

Is there a recommended best practice for deployment that can mitigate this issue? For example, would having each node point to a central HTTP farm URL help at all, since it might be easier to trigger hot deployment everywhere by updating the "last modified" time on the centrally-distributed file?

Sure, this would work. Others have followed this approach as well to work around the farm deployment issues. The central farm url (perhaps a shared filesystem) can be a single point of failure but you could add a secondary (alternative) farm folder in case the shared filesystem crashes.

Regarding your other question of what the timetable is for fixing this. The problem has been recorded in the Jira system and design forums, however, there is no timetable set for resolving these issues.

http://jira.jboss.com/jira/browse/JBAS-1322 describes the problem that you have hit.

http://jira.jboss.com/jira/browse/JBAS-2326 describes a problem that you could hit if connectivity between nodes breaks and latest resumes (cluster nodes continue to run throughout this situation but do not react to changes made while disconnected from the rest of cluster.)