Nandika, I very well understand what you have put across, but it's secondary to me now.
Sudharma, My primary concern is to understand at a high level the deployment architecture and how would master-slave configuration fit in. Are there any restrictions imposed by the in-progress design? Firstly, how would ODE process deployment work under these cluster configurations? Sample Cluster configurations: A load balancer is frontending the servers. 1) Cluster consisting of 2 nodes all Active-Active. 2) Cluster consisting of 2 nodes Active-Passive. 3) Cluster with 2+ nodes with additional nodes either in Active or Passive. regards, sathwik On Wed, May 27, 2015 at 3:04 PM, Nandika Jayawardana <jayaw...@gmail.com> wrote: > Hi Sathwik, > > According to my understanding, in the clustering scenario, the master node > should perform all the deployment actions and the slave nodes also need to > perform some deployment actions. For example, the slave nodes also should > handle the process ACTIVATED event so that the process configuration is > added to the engine and necessary web services are created so that when the > load balancer send requests to any node in the cluster, it is ready to > accept those requests. > > Regards > Nandika > > > > > On Wed, May 27, 2015 at 12:30 PM, Sathwik B P <sathwik...@gmail.com> > wrote: > > > Sudharma, > > > > Where are you going to configure the master-slaves, is it in the web > > application level or at the load balancer? > > > > regards, > > sathwik > > > > On Tue, May 26, 2015 at 7:42 PM, sudharma subasinghe < > > suba...@cse.mrt.ac.lk> > > wrote: > > > > > Hi Tammo, > > > > > > Can you suggest the best method from these to implement? As first I > > > suggested the master-slaves scenario I think it is easy to implement > than > > > distributed lock scenario. However if you can suggest one from these > two, > > > then I can think about it. > > > > > > Thank you > > > > > > On 21 May 2015 at 12:40, Sathwik B P <sathwik...@gmail.com> wrote: > > > > > > > With respect to the hotdeployment, > > > > > > > > We can drop the deployment archive onto the deployment folder. Since > > the > > > > DeploymentPoller are acquiring the distributed lock for the > > > DeploymentUnit, > > > > only one of the nodes will get the lock and initiate the deployment. > > > > DeploymentPollers on other nodes will fail in acquiring the lock and > > > hence > > > > will silently ignore it. > > > > > > > > On Thu, May 21, 2015 at 12:30 PM, Sathwik B P <sathwik...@gmail.com> > > > > wrote: > > > > > > > > > Hi Tammo, > > > > > > > > > > The distributed lock acquisition on the DeploymentUnit should be > > added > > > to > > > > > both DeploymentWebService and DeploymentPoller. > > > > > > > > > > When a deployment operation is initiated through the > > > > DeploymentWebService, > > > > > The load balancer routes it to any of the available nodes. > > > > > > > > > > On the routed node, the DeploymentWebService acquires the > Distributed > > > > > lock. On the remaining nodes the DeploymentPoller will try to > acquire > > > the > > > > > distributed lock and will not get it and hence will silently ignore > > it. > > > > > > > > > > Once the routed node completes the deployment, it will release the > > > lock. > > > > > This way we don't have to stall the DeploymentPoller in other > nodes. > > > > > > > > > > Does it answer the concerns? > > > > > > > > > > > > > > > Now, if we give the responsibility of identifying the master node > to > > > the > > > > > hazelcast, how do we plan to intimate the load balancer to change > > it's > > > > > configuration about the master node? > > > > > Assuming there are 3 nodes in the cluster, > > > > > node1 -master > > > > > node2 - slave > > > > > node3 - slave > > > > > > > > > > Node1 goes down, the LB will promote Node2 as master node, but > > > hazelcast > > > > > might promote Node3 as master node. They are out of sync. > > > > > > > > > > Is this argument valid? > > > > > > > > > > regards, > > > > > sathwik > > > > > > > > > > On Wed, May 20, 2015 at 1:51 PM, Tammo van Lessen < > > > tvanles...@gmail.com> > > > > > wrote: > > > > > > > > > >> Hi Sudharma, > > > > >> > > > > >> what do you expect from the "other nodes deployment"? Compilation > is > > > not > > > > >> needed since the CBP file is written to the (shared) FS. > > Registration > > > is > > > > >> also not needed, since it is done via the shared database. So the > > only > > > > >> thing that might be needed is to tell the engine that there is a > new > > > > >> deployment. I'd need to check that. If this is needed, I revert my > > > last > > > > >> statement, then it is perhaps better to just send an event over > > > > Hazelcast > > > > >> to all nodes that the deployment has changed. > > > > >> > > > > >> Best, > > > > >> Tammo > > > > >> > > > > >> On Wed, May 20, 2015 at 10:13 AM, sudharma subasinghe < > > > > >> suba...@cse.mrt.ac.lk > > > > >> > wrote: > > > > >> > > > > >> > Hi Tammo, > > > > >> > > > > > >> > The master node writes meta data. But runtime information must > be > > > > >> available > > > > >> > in all nodes.Since the folder is shared, all nodes will see the > > > > >> > availability of a new process. My idea is for master node to > write > > > the > > > > >> meta > > > > >> > data and other nodes to just read the meta data and load > > process.So > > > we > > > > >> need > > > > >> > a small delay between master node deployment and other nodes > > > > deployment. > > > > >> > > > > > >> > Is there anyway to set the delay between master node and slaves > > > until > > > > >> > master node finish the deployment? > > > > >> > > > > > >> > Thank you > > > > >> > Sudharma > > > > >> > > > > > >> > > > > > >> > On 20 May 2015 at 13:01, Tammo van Lessen <tvanles...@gmail.com > > > > > > wrote: > > > > >> > > > > > >> > > Hi Sathwik, > > > > >> > > > > > > >> > > On Wed, May 20, 2015 at 6:40 AM, Sathwik B P < > > > sathwik...@gmail.com> > > > > >> > wrote: > > > > >> > > > > > > >> > > > Sudharma/Tammo, > > > > >> > > > > > > > >> > > > 1) How do we plan to decide which is the master node in the > > > > cluster? > > > > >> > > > > > > > >> > > > > > > >> > > I think the easiest approach is to always elect the oldest > node > > in > > > > the > > > > >> > > cluster to be the master. AFAIK Hazelcast can easily asked for > > > this > > > > >> > > information. > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > 2) Don't we need to stall the Deployment Pollers in the > slave > > > > nodes? > > > > >> > > > > > > > >> > > > > > > > >> > > Absolutely. > > > > >> > > > > > > >> > > Suggestion: > > > > >> > > > I am not sure whether do we need Master-SLaves. Why not give > > > every > > > > >> node > > > > >> > > in > > > > >> > > > the cluster the same status (Active-Active). > > > > >> > > > > > > > >> > > > When a new deployment is made, the load balancer can push it > > to > > > > any > > > > >> of > > > > >> > > the > > > > >> > > > available nodes. That node will probably acquire a > distributed > > > > lock > > > > >> on > > > > >> > > the > > > > >> > > > deployment unit and acts as master for that deployment. This > > > > ensures > > > > >> > > > optimum usage of the cluster nodes. Probably no static > > > > >> configuration of > > > > >> > > > Master-Slave in the load balancer nor in the hazelcast. > > > > >> > > > > > > > >> > > > > > > >> > > But this would not allow to have the hotdeployment via > > filesystem > > > > >> still > > > > >> > > enabled, right? > > > > >> > > > > > > >> > > Best, > > > > >> > > Tammo > > > > >> > > > > > > >> > > > > > > >> > > -- > > > > >> > > Tammo van Lessen - http://www.taval.de > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > > >> > > > > >> -- > > > > >> Tammo van Lessen - http://www.taval.de > > > > >> > > > > > > > > > > > > > > > > > > > >
