Hi Devs, I have now completed the initial implementation of $subject and pushed those changes to master branch.
Thanks On Fri, Nov 28, 2014 at 1:49 PM, Gayan Gunarathne <gay...@wso2.com> wrote: > Hi, > > On Fri, Nov 28, 2014 at 1:00 PM, Akila Ravihansa Perera < > raviha...@wso2.com> wrote: > >> Hi, >> >> According to this design Autoscaler (AS)/Stratos Manager (SM) will talk >>>> to Cloud Controller (CC) via the Cloud Controller Service endpoint exposed >>>> via the load balancer. >>>> >>>> *Data Replication* >>>> When a request comes into one of the CC instances it will execute the >>>> necessary actions and update the data holder and/or topology which is in >>>> memory. At this point the data holder changes will be replicated to other >>>> instances using a distributed map. Once the coordinator receives the above >>>> updates it will persist the changes to the registry database. >>>> >>> >>> Are we sending a notification (cluster message) when the distributed map >>> updated? >>> >> >> This is handled by Hazelcast OOTB right? >> >> >>>> In this design we might not need to replicate the topology since it is >>>> already there in the message broker. The idea is to let coordinator publish >>>> the topology changes and the other members to listen to it. >>>> >>> >> So that means worker nodes listen to the topology as well as cluster >> messages? I think we need to clarify this model a bit more. >> >> >>> >>> This would add a latency for the events. What are the issues we would >>> face, when each node sends out the event? Of course, the complete topology >>> should only be sent out by the Coordinator. >>> >> >> Sending out multiple topology events (for eg - MemberActivated, >> MemberTerminated) will trigger many listeners multiple times, and that's >> probably not a good idea. Or did you mean something else here, sorry I'm >> bit confused. >> > > IMO coordinator is the one who needs to make persistence and message > publishing.Other instance responsibility to handle the request and update > the in-memory data grid. > >> >> >>> Also, we need to make CC data publishers activated only when a node is >>> the Coordinator. >>> >>> Further, only the Coordinator should react to the Instance status events >>> etc. IMO. >>> >> >> I think this might result in an inconsistent state if the coordinator >> fails while processing an instance status event (or any other event for >> that matter). Perhaps we can implement a notifier cluster message to >> indicate whether incoming events are processed successfully. If the >> coordinator fails, the next elected coordinator should be able to pick up >> from the last successful event handled. >> > > +1 we may need to synchronous the new coordinator with the last > coordinator status. I guess we may need maintain the coordinator status. > >> >> >>> There's a cache to hold the validated partitions of a Cartridge, we need >>> to use a distributed hash map for that too. >>> >> >> +1 >> >> >>>> Please add your thoughts. >>>> >>>> Thanks >>>> >>>> >>>> -- >>>> Imesh Gunaratne >>>> >>>> Technical Lead, WSO2 >>>> Committer & PMC Member, Apache Stratos >>>> >>> >>> >>> >>> -- >>> Best Regards, >>> Nirmal >>> >>> Nirmal Fernando. >>> PPMC Member & Committer of Apache Stratos, >>> Senior Software Engineer, WSO2 Inc. >>> >>> Blog: http://nirmalfdo.blogspot.com/ >>> >> >> >> >> -- >> Akila Ravihansa Perera >> Software Engineer, WSO2 >> >> Blog: http://ravihansa3000.blogspot.com >> > > > > -- > > Gayan Gunarathne > Technical Lead > WSO2 Inc. (http://wso2.com) > email : gay...@wso2.com | mobile : +94 766819985 > > -- Imesh Gunaratne Technical Lead, WSO2 Committer & PMC Member, Apache Stratos
