[Clustering/JBoss] - Re: Cluster Deployment: farming
by bstansberry＠jboss.com
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.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4160695#4160695
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4160695
17 years, 9 months
[JBoss Messaging] - JBoss Messaging and Bisocket Transport
by ebenezerlovelin
Hi,
JBoss AS: 4.2.2.GA
JBM: 1.4.0.SP3
Remoting: 2.2.2.SP7-brew
We are planning to use Http Transport instead of Bisocket Transport in JBoss Messaging; this is because we have an external load balancer which would balance the load across all the messaging instances (We have 5 JBoss Server running in 5 Physical Machines and one JBoss instance in each Server and there are many senders that would be sending messages and the load balancer would spread the load across the queues in a round robin fashion). Now we are unable to use bisocket transport because it opens a second port 4457 and keeps it open and our load balncer is configured to use 1099 and because the second port is always open, the load balancer is unable to do its work. Basically, when the load balancer gets the very first message, it chooses a instance to which it sends the message and then when the second message comes, it HAS to choose the next instance, BUT, that doesnt happen since the bisocket transport has a second port that is always open, the load balancer chooses the first machine to send the other messages that comes.
Is there any way that we can stop the opening of the second port that is being opened by the Bisocket transport?
BTW, I have read that bisocket transport is useful in place where the server is behind a firewall and this server opens the call back port (the second port 4457, here) so that clients can use that. Our Server is not behind a firewall and so we do not want the call back port.
Thanks,
Ebe
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4160691#4160691
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4160691
17 years, 9 months
[Clustering/JBoss] - Re: Cluster Deployment: farming
by sankul123
"bstansberry(a)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(a)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 -
anonymous wrote : 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
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4160686#4160686
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4160686
17 years, 9 months