4 Replies Latest reply on Jun 25, 2008 6:53 PM by brian.stansberry

    Cluster Deployment: farming

    sankul123

      Need some clear[simple :)] clarifications[please]-

      1.Farming service-
      When we say farming service , I believe that I need not worry about keeping the application context synch in cluster.
      For ex: we have some feature to upload files.
      So in a cluster with N1,N2,N3 and if file upload request is served by N1 node, the uploaded file on N1 is also replicated on nodes N2,N3 .
      Please clarify this if I my understanding is wrong.

      2.Farming deployment
      If I hot-deploy the application
      archive file (the EAR) in the all/farm/ directory of any of the cluster member
      and the application is automatically duplicated across all nodes in the same cluster. In our application we have features to upload files[these are ETL related job files] to server.

      For now I am deploying the application ear in server type default/deploy, what I observe is that the ear is exploded every time I start/restart my jboss server.I am not able to see the files uploaded files after restart of Jboss as ear file gets exploded to new tmp folder? If this is the behaviour then people are going to kill me if the ear is exploded every time, lots of configurations in properties file will be lost. The solution that was proposed to me for this is to deploy application as exploded directory - http://www.jboss.com/index.html?module=bb&op=viewtopic&t=137796

      Now what I see from cluster doc is that farming service is only supported if hot deployed as ear archive? Will my files uploaded[through upload file feature,which are not part of ear archive] , or any configuration done to my properties file be lost on restart of cluster?


      Above all I am sorry for this big post ,but could not help as I did not get clear clarification from many other JBoss cluster GURU's :).

      Sandeep

        • 1. Re: Cluster Deployment: farming
          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

            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

               

              "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

                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.