-
1. Re: Cluster Deployment: farming
sankul123 Jun 20, 2008 7:41 PM (in response to sankul123)Can someone through some light on this?
I need to make a decision on whether I should go with archived ear file or exploded directory deployment.
Sandeep -
2. Re: Cluster Deployment: farming
brian.stansberry Jun 20, 2008 9:00 PM (in response to sankul123)I don't understand your question. Are you saying you try to edit files in the default/tmp folder but then find they get overridden from the content in default/deploy when you redeploy? But an exploded archive lets you edit the exploded content?
Well, anyway, you can't deploy exploded archives to the farm folder.
And your description of "farming service" doesn't describe any service provided by JBoss. There is no feature to replicate uploaded files around a cluster (except if you did something like store the file content byte[] as an attributed in a clustered web session). -
3. Re: Cluster Deployment: farming
sankul123 Jun 25, 2008 6:09 PM (in response to sankul123)"bstansberry@jboss.com" wrote:
I don't understand your question. Are you saying you try to edit files in the default/tmp folder but then find they get overridden from the content in default/deploy when you redeploy? But an exploded archive lets you edit the exploded content?
I am sorry for the confusion, I meant to say that a previously exploded context is lost once you restart the Jboss server.
Consider following myApp.ear for example -myApp.ear | | |-------myWeb.war | | | |-------config | | | | | |-------customConfig.properties[configurations are lost after restarts] | | | | | | |-------upload[User uploads few config input file. Uploaded files are also lost on restarts of server] | | | | | |------- aInput.xml | | |------- bInput.xml | | |------- cInput.xml | |
myApp.ear archived file is deployed under ${jboss.home}\server\default\deploy\ then its content will be exploded to default\tmp\deploy\tmp1234myApp-contents.ear[with some namimg protocol of Jboss].
Any configuration changes done to customConfig.properties file resides inside exploded context tmp1234myApp-contents.ear directory. Similarly any file uploads done to the context will also reside in this temp exploaded directory.
Once we restart Jboss server, it deletes all contents of ${jboss.home}\server\default\tmp\deploy folder,where the ear files are exploaded and exploads are the ear files again.
Since modification done to the exploaded application[context] resides in tmp\deploy\, are lost after restart.When server is restarted ear file is extracted again to tmp\deploy folder.
All configurations done on previously exploaded application are lost."bstansberry@jboss.com" wrote:
And your description of "farming service" doesn't describe any service provided by JBoss. There is no feature to replicate uploaded files around a cluster (except if you did something like store the file content byte[] as an attributed in a clustered web session).
And for this I still need some more clarification -
From Cluster guide -The easiest way to deploy an application into the cluster is to use the farming service. That is to hot-deploy the application
archive file (e.g., the EAR, WAR or SAR file) in the all/farm/ directory of any of the cluster member
and the application is automatically duplicated across all nodes in the same cluster. If node joins the cluster later, it
will pull in all farm deployed applications in the cluster and deploy them locally at start-up time. If you delete the
application from one of the running cluster server node's farm/ folder, the application will be undeployed locally
and then removed from all other cluster server nodes farm folder (triggers undeployment.) You should manually
delete the application from the farm folder of any server node not currently connected to the cluster
What if there is any modifcation to the context , as explained in above in myApp.ear issue example.If there is a file upload to the context? how will this be communicate to other nodes?
I dont see any thing that explain my doubt in cluster guide/doc, please let me know if my understanding is wrong.
If Jboss does not support replication of context , should we use any cluster software to do that?
Regards,
Sandeep -
4. Re: Cluster Deployment: farming
brian.stansberry Jun 25, 2008 6:53 PM (in response to sankul123)OK, I see what you are getting at.
Farming isn't going to do what you want. Even if it supported exploded deployments, it wouldn't do what you want. It would just monitor the web.xml file and copy the war content around the cluster if that file changed. It's not a general purpose file replication service.
In general, I don't think trying to edit the content of the tmp/ dir is correct usage. People do it to .jsp files to avoid having to redeploy a war to pick up a minor jsp change, but the expectation is those updated jsps will be included in any new version of the war copied to deploy. It's better to store data that isn't packaged in teh deployment itself but is expected to survive a redeploy in the server/.../data dir -- that's the purpose of that dir.
If you want files that users upload to be reflected around the cluster, you'll need to come up with your own solution for that. There is no standard service JBoss AS provides. Possibilities are storing them in NFS mount, using some file replication software outside of JBoss AS, or perhaps using JBoss Cache. JBC can of course replicate content and can also be configured to store a copy of the file on the local filesystem.