Hi I am new to this forum as well as weblogic server.My requirement is that I have an application that runs on a cluster having an admin server and three managed server MS1,MS2,MS3.Currently my application has two parts(or logic), both of which are in a single ear file.The part1 always occupies one server, say MS1 and rest in other two MS2 & MS3 .I want to divide my code in two different ear part1 and part2 with par1_ear deployed in MS1 and part2_ear deployed in MS2 and MS3 all running under same admin server
ear1 deployed in ----->MS1
ear2 deployed in ----->MS2 &MS3
All running under same managed server.
Can this be done if not other suggestion also welcome but i can have only one admin server and 3 clusters
Yes, when you deploy your .ear files you can target specific machines in a cluster. Your deployments don't have to go to all machines in a cluster.
Also, if you really only want one server in the cluster to handle some specific event you might want to look into Singleton Services.
Have you had experience deploying applications in Weblogic before?
Related
We are using Jboss 7 App Server and we are trying run multiple server nodes on a single box and also on other box *basically 2 boxes which will have 2 each nodes of Jboss servers running).
My question is to have multiple nodes of Jboss Servers on a single box in Standalone mode. Should I have to copy server folder twice with port offsets?
Or is it ok to start servers just via port offset without having to copying server folder?
What is the best practice to have multiple server nodes running on the same box? Any advice would be greatly appreciated.
Thank you.
Just create multiple copies of standalone directory(Example: standalone_PROD,standalone_SIT) so that we will have separate log files and deployment directories for each instance. And use below option while starting server instance:
-Djboss.server.base.dir=/path/to/standalone_SIT <-- Location of standalone dir
-Djboss.socket.binding.port-offset=10 <-- PortOffset to avoid port conflict
We have had two instances of jboss on the same computer over several years. Both instances were in the same domain. Each instance had its own port and of course lay in its own path. Our experiences were good.
You can have as many standalone instances you want on a machine, depending upon the resources available.
All you need to do is copy over the same folder twice and make changes in all the ports to be used in the standalone mode. Also If you are setting any parameters make sure they are according to the memory available on the machine.
I wanna deploy the Spring-cloud-data-flow on several hosts.
I will deploy the server of Spring-cloud-data-flow on one host-A, and deploy the agents on the other hosts(These hosts are in charge of executing the tasks).
Except the host-A, all the other hosts run the same tasks.
Shall I modify on the basis of the Spring Cloud Data Flow Local Server or on the Spring Cloud Data Flow Apache Yarn Server or other better choice?
Do you mean how the apps are deployed on several hosts? If so, the apps are deployed using the underlying deployer implementation. For instance, if it is local deployer then, each app is deployed by spawning a new process. You can scale out the number apps deployment using the count property during the stream deploy. I am not sure what do you mean by the agents here.
I have been using SCDF for a while, and realise the main diffs between XD and SCDF is XD is born to be distributed, but SCDF seems work like a platform for SC stream apps. At least local server works like so.
So my question is, is it possible that scdf local server being distributed? I see no trends on local server being distributed.
Any idea on this? thanks
As you might have known already, the local server is not intended for production deployments and for the development purpose only.
The local SCDF server is not intended to have distributed use case as there is no co-ordination service for the number of local servers running. But all the apps deployed by the local server run as separate processes.
I have configured a Soa Cluster with one admin node and two managed nodes and all server nodes configured in three different machines. once I deploy a Bpell to one managed node it automatically deploys in the other managed nodes as well(default behavior). once you go to soa enterprise manager those deployed Bpels can be viewed under [Soa -> managed node -> Defult ->..]. It is the same place where we deploy new Bpels. I accidentally undeploy all bpels (you can do it by right clicking a managed node and choosing un-deploy option).
Now I'm having a hard time to get back to previous state, how to deploy all those projects again to a specific managed node. I tried to restart the node hoping it would sync again, yet the managed server went to "admin" state (not the ok state).
is there anything needs to be done !!
Thanks, Hemal
You'll need to start the server from command line, it will work.
For managing 'managed servers' from EM or WLS console, there's one additional step that's needed during instalation process.
Please modify the nodemanager.properties of WLS and set the property startscriptenabled=true.
http://download.oracle.com/docs/cd/E12839_01/core.1111/e10105/start.htm#CIHBACFI
We have a J2EE application as EAR file which is deployed in WAS 7, for making the application availability as high it needs to be deployed in 3 clusters. We have a Quartz Scheduler class whose job is to upload data from one database to another daily at 2:00 am.
Now, the problem is if the ear will be deployed in 3 different nodes for load balancing and high availability, all the 3 ear file will trigger the upload at the same time. How we can handle this. Is it possible to do some configuration in WAS 7 environment. Any help/suggestion would be appreciated.
Thanks
You have two possibilities:
The Quartz database backend where all your nodes would connect to the same database that Quartz uses for synchronizing the task running. This can be configured to prevent the task from running on several nodes simultaneously.
EJB 3.x timer. See for instance this example. This however works for ensuring that only member from each of the clusters fire the timer.