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 > > >> > > > > > > > > >
