Hi Sathwik, I can't find the attached document. Please kind be enough to resend it.
On 6 June 2015 at 15:42, Sathwik B P <sathwik...@gmail.com> wrote: > Refer this one as I have corrected the numbering of steps. > > On Sat, Jun 6, 2015 at 3:33 PM, Sathwik B P <sathwik...@gmail.com> wrote: > >> Hi Sudharma/Tammo, >> >> Kindly review attached document on my proposed approach. Let me know if >> you have any concerns or doubts on it. >> >> regards, >> sathwik >> >> On Fri, Jun 5, 2015 at 6:56 PM, Sathwik B P <sathwik...@gmail.com> wrote: >> >>> find response inline >>> >>> On Wed, Jun 3, 2015 at 10:22 PM, sudharma subasinghe < >>> suba...@cse.mrt.ac.lk> wrote: >>> >>>> Hi, >>>> >>>> Sorry for the late reply. I was trying to achieve a proper solution. >>>> Following is my approach. >>>> >>>> 1) I elected master node for deploying purpose. So when a master node >>>> goes >>>> down hazelcast will elect the next oldest node for master. >>>> >>> >>> Perfect >>> >>> >>>> 2) ODEServer can identify whether clustering is enabled or not by >>>> getting >>>> the property value in ode-axis2.properties file. So I introduced new >>>> property called "ode-axis2.hazelcast.clustering.enabled". If there is no >>>> clustering enabled server will work as it is. If clustering is enabled, >>>> cluster will be initialized. >>>> >>> >>> Perfect >>> >>> >>>> 3) In manual deployment its responsibility is taken by the >>>> DeploymentPoller. So I give the deployment capability to master node,s >>>> poller by setting "isDeploymentFromODEFileSystemAllowed()" to true.So >>>> others will not be able to go into check() method in DeploymentPoller. >>>> So >>>> deployment will be done by only the master node. >>>> >>> >>> Perfect >>> >>> >>>> >>>> 4) In DeploymentWebService, I had to consider few cases.If the deploy >>>> request goes to the master node, it will deploy the process through web >>>> service.Others pollers will not go into check() method as they are not >>>> masters. So master can continue without any involvement of others. >>>> >>>> >>> Perfect >>> >>> >>>> 5) If the deploy request goes to a slave node, it will do up to file >>>> creation in the file system.Slave will be stopped at that point. As only >>>> master poller is checking, master can continue from created files in the >>>> file system. >>>> >>> >>> DeploymentWebService provides synchronous operations. The status of >>> the operation should be communicated to the calling client in the same call. >>> DeploymentPoller is a backend thread that goes over each and every >>> directory under the Deployment directory checking for any changes to >>> deploy.xml in existing processes and deploy newly added processes. This >>> process is sequential and time consuming. As the process directories >>> grows, so does the time taken for execution of the thread. >>> >>> Since the request is on a slave node and the processing is done on >>> master node, how do you check for the completion of the >>> deployment/undeployment of processes and respond back to the client since >>> the web service call is a synchronous operation. As DeploymentPoller is >>> taking a lot of time in processing, your request will time out right. >>> >>> >>>> >>>> 6) But there was problem with _deploymentUnits in ProcessStoreImpl. Each >>>> _deploymentUnits stores only what its server has deployed. So think, >>>> that a >>>> master node goes down another master node appears.But its >>>> __deploymentUnits >>>> does not have dus which has deployed by the earlier master node. Hence >>>> it >>>> will not be able retire earlier version of the process which is >>>> deployed by >>>> previous master. So there will two process which are in "ACTIVE" state >>> >>> >>>> 7) To avoid this, I add the ODEServer as an Observer to check when a new >>>> master is electing, then load all the deployment units out of the >>>> store. So >>>> new master node can have all the dus and can retire appropriate version. >>>> Usually loadAll() is called at the server start-up time. But there is no >>>> other way to solve this. I tried to use Hazelcast IMap to store all dus >>>> among all nodes. But it wasn't success as du is not serializable >>>> object. >>>> >>> >>>> 8) I figured out that we do not need send cluster message to others as >>>> all >>>> the dus' data are persisted to the shared DB. So each node can take the >>>> du >>>> and retrieve necessary data using already implemented methods in Process >>>> Store. >>>> >>>> 9) But there is an another problem.The axis2 service corresponding to a >>>> deployed process does not appear on all nodes of the cluster. That is >>>> because each server add du which is deployed by it to the process >>>> store.That is why I had use loadAll() when masters are changing. How to >>>> solve this? >>>> >>> >>> I do appriciate your efforts in understanding the implmentation and >>> changes that need to be done. You are bang on it. >>> fireEvent(..) is the method that triggers process activation and >>> necessary service creation. >>> >>> >>> But with this given apporach from steps 6 to 8, ODE cannot have >>> atleast 2 Active servers for Load balancing. You are concentrating on only >>> one active node that will do deployments and cater to process invocations. >>> We should also think about scaling ODE to multiple servers to handle >>> load. >>> >>> What do you think. >>> >>> >>>> Thank you, >>>> Sudharma >>>> >>>> On 2 June 2015 at 08:51, Sathwik B P <sathwik...@gmail.com> wrote: >>>> >>>> > Sudharma, >>>> > >>>> > Any updates? >>>> > >>>> > regards, >>>> > sathwik >>>> > >>>> > On Fri, May 29, 2015 at 5:26 PM, Sathwik B P <sathwik...@gmail.com> >>>> wrote: >>>> > >>>> > > Sudharma, >>>> > > >>>> > > Can you elaborate on your option 1). >>>> > > >>>> > > Response to your option 2). >>>> > > >>>> > > Process Store is the component that handles process metadata, >>>> > > compilation and deployment in ODE. Integration layers in ODE >>>> (Axis2, JBI) >>>> > > use the process store. >>>> > > Future implementations of IL for ODE will also use the process >>>> store. >>>> > > We should not be thinking of moving the process store functionality >>>> to >>>> > the >>>> > > integration layers. >>>> > > >>>> > > >>>> > > On Thu, May 28, 2015 at 9:33 PM, sudharma subasinghe < >>>> > > suba...@cse.mrt.ac.lk> wrote: >>>> > > >>>> > >> Hi, >>>> > >> >>>> > >> I understood the problem within dynamic master/slave >>>> configuration. In >>>> > my >>>> > >> approach, when a deployment request is routed to a slave node >>>> there will >>>> > >> not be a deployment. I suggest two options to avoid it. >>>> > >> 1) Have static master/slave configuration only for deploy process >>>> > >> >>>> > > 2) Modify the deployment web service to complie and verify the >>>> process >>>> > and >>>> > >> then copy it to the deploy folder irrespective of whether its a >>>> master >>>> > or >>>> > >> slave, then deployment poller should take care of the deployment >>>> > >> >>>> > >> >>>> > > >>>> > >> >>>> > >> On 28 May 2015 at 14:43, Sathwik B P <sathwik...@gmail.com> wrote: >>>> > >> >>>> > >> > Sudharma, >>>> > >> > >>>> > >> > We definitely need a master/slave in the hazelcast cluster. This >>>> is >>>> > >> > probably needed for the job migration in the Scheduler to >>>> migrate the >>>> > >> jobs >>>> > >> > associated with a down node. Let hold on this topic for future >>>> > >> discussion. >>>> > >> > >>>> > >> > Going by the explanation where the master/slave nodes have >>>> certain >>>> > >> > predefined tasks to perform is perfectly fine. >>>> > >> > >>>> > >> > I have this scenario, >>>> > >> > >>>> > >> > I am using HAProxy as my load balancer and configured 3 nodes in >>>> the >>>> > >> > cluster. >>>> > >> > >>>> > >> > Node1 - Active >>>> > >> > Node2 - Active >>>> > >> > Node3 - Backup >>>> > >> > >>>> > >> > Load balancing algorithm: RoundRobin >>>> > >> > >>>> > >> > A Backup node (Node3) is one which the load balancer will not >>>> route >>>> > >> > requests to, until one of the Active node i.e either Node1 or >>>> Node2 >>>> > has >>>> > >> > gone down. >>>> > >> > >>>> > >> > All these 3 nodes are also part of the hazelcast cluster as well. >>>> > >> > >>>> > >> > In the hazelcast cluster, assume Node1 is elected as the >>>> leader/master >>>> > >> and >>>> > >> > Node2,Node3 as slaves. >>>> > >> > >>>> > >> > I initiate the deploy operation on the DeploymentWebService >>>> which the >>>> > >> load >>>> > >> > balancer routes it to one of the Active nodes in the cluster, >>>> lets say >>>> > >> it's >>>> > >> > the Node1. Since Node1 is also the master in the hazelcast >>>> cluster, >>>> > >> > deployment is a success. >>>> > >> > >>>> > >> > I initiate another deploy operation on the DeploymentWebService >>>> which >>>> > >> the >>>> > >> > load balancer routes it to the next active node which is Node2. >>>> Since >>>> > >> Node2 >>>> > >> > is a slave in the Hazelcast cluster, What happens to the >>>> deployment? >>>> > >> > >>>> > >> > regards, >>>> > >> > sathwik >>>> > >> > >>>> > >> > On Wed, May 27, 2015 at 10:55 PM, sudharma subasinghe < >>>> > >> > suba...@cse.mrt.ac.lk >>>> > >> > > wrote: >>>> > >> > >>>> > >> > > Hi, >>>> > >> > > >>>> > >> > > I will explain my approach as much as possible. The oldest >>>> node in >>>> > the >>>> > >> > > hazelcast cluster is elected as the master node. In the >>>> failure of >>>> > the >>>> > >> > > master node, next oldest node will be elected as the master >>>> node. >>>> > This >>>> > >> > > master-slave configuration is just for deployment. When the >>>> > hazelcast >>>> > >> > > cluster elected the master node, that node becomes a master >>>> node for >>>> > >> > > deploying process. So it will do the deploying artifacts. If >>>> you >>>> > want >>>> > >> to >>>> > >> > > get the idea of electing master node please refer the code >>>> which I >>>> > >> have >>>> > >> > > located in the github. ( >>>> > >> > > https://github.com/Subasinghe/ode/tree/ode_clustering) >>>> > >> > > >>>> > >> > > I identified separated actions which should be followed by the >>>> > master >>>> > >> and >>>> > >> > > salve nodes. >>>> > >> > > Actions which are followed by master node only >>>> > >> > > 1) create deployment unit >>>> > >> > > 2) set the version nu to deployment unit >>>> > >> > > 3) compile deployment unit >>>> > >> > > 4) scan deployment unit >>>> > >> > > 5) retire previous versions >>>> > >> > > Master node and slave nodes should create _processes which >>>> stores >>>> > >> > > ProcessConfImpl >>>> > >> > > Only master node will write the version nu to database, create >>>> > >> .deployed >>>> > >> > > file >>>> > >> > > >>>> > >> > > So there are some actions which should be followed only by >>>> master >>>> > node >>>> > >> > > while other actions should be followed by all the nodes.The >>>> idea of >>>> > >> > having >>>> > >> > > a master node is deploying artifacts and avoid others from >>>> writing >>>> > the >>>> > >> > > version nu to database. >>>> > >> > > Whether a node is active or passive, all nodes should do the >>>> > >> > > deployment.Master >>>> > >> > > and slaves will follow necessary actions as in above. >>>> > >> > > >>>> > >> > > >>>> > >> > > >>>> > >> > > >>>> > >> > > >>>> > >> > > On 27 May 2015 at 15:49, Sathwik B P <sathwik...@gmail.com> >>>> wrote: >>>> > >> > > >>>> > >> > > > 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 >>>> > >> > > > > > > > >> >>>> > >> > > > > > > > > >>>> > >> > > > > > > > > >>>> > >> > > > > > > > >>>> > >> > > > > > > >>>> > >> > > > > > >>>> > >> > > > > >>>> > >> > > > >>>> > >> > > >>>> > >> > >>>> > >> >>>> > > >>>> > > >>>> > >>>> >>> >>> >> >