-
1. Re: Cold Deployment
ben.wang Jul 6, 2006 8:51 PM (in response to 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?
-
2. Re: Cold Deployment
jleech Jul 7, 2006 11:20 AM (in response to 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? -
3. Re: Cold Deployment
brian.stansberry Jul 7, 2006 11:37 AM (in response to jleech)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.
-
4. Re: Cold Deployment
evk Jul 7, 2006 12:51 PM (in response to jleech)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 -
5. Re: Cold Deployment
smarlow Jul 7, 2006 2:48 PM (in response to jleech)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.)