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 >
