Hi Azeez, AFAIU, this has to be implemented at some central code, since this has to happen for both the UM and the registry caches at the same time. Therefore, this is not just a G-Reg only fix.
Hi Sagara, Yes, this approach looks good. Thanks, Senaka. On Sun, Apr 6, 2014 at 3:51 AM, Sagara Gunathunga <[email protected]> wrote: > > > Hi Azeez/Senaka, > > There are few aspects related to cache invalidation here. > > 1.) Time out based cache invalidation - ( Right now it's broken for GReg > but we will fix it and let's leave it) > > 2.) Cache invalidation across the platform - This is where we bring this > pub-sub based approach. The overhead of this approach is it requires a > broker, but given the fact that this should smoothly work across whole > stack users can decide whether to satisfy with 1.) or bring a broker so > not a problem. > > 3.) Cache invalidation across the GReg cluster - Today this is supported > and not a problem according to the cluster architecture as well. > > So how we going to support this option 3.) ? > > a.) If a broker is already available in the architecture then are we > delegate cache invalidation among Greg node also to the broker ? > > b.) In case there is no broker available still users should able to > invalidate cache among Greg nodes in that case we could keep existing > cluster based mechanism too. IMO it's hard to expect to bring a new broker > component just do the cache invalidation with same cluster and some may can > consider it as story broken for cache. > > > > Personally I'm thinking about following architecture. > > > 1. We keep existing cluster based cache invalidation as it is but not > recommend to use it among different product clusters. > > 2. Enable pub-sub model only to communicate cache invalidation messages > among clusters not among each individual node. > > 3. Cluster representative - There is a kind of an agent or one member > from each cluster can subscribe with broker and this guy can > publish/receive messages in behalf of his cluster. > > > WDYT ? > > Thanks ! > > > On Fri, Apr 4, 2014 at 2:37 PM, Afkham Azeez <[email protected]> wrote: > >> >> >> >> On Fri, Apr 4, 2014 at 5:44 PM, Amal Gunatilake <[email protected]> wrote: >> >>> Hi Azeez/Senaka, >>> >>> I have implemented the JMS publisher and receiver as a separate >>> component. These interfaces will register a topic in the ActiveMQ server >>> and each cluster node can subscribe to the topic. Once GReg cluster publish >>> the message to the topic the subscribers will receive the message. >>> >>> In-order to implement the next step which is passing and updating the >>> correct data, I need to know the following. >>> >>> 1. Which section of the code I need to focus in Kernel where cache >>> invalidation happens in GReg (Hazelcast Cache add, delete, update)? >>> >>> In GReg, wherever relevant resources are updated, and cache needs to be >> globally (across multiple clusters) invalidated, your OSGi service should >> get called. Let's call that service GlobalCacheInivalidationService >> >> >>> >>> 1. >>> 2. Which section of the code I need to focus in Kernel where >>> individual nodes get update in a cluster with Hazelcast? >>> >>> >> In the kernel, we just need to add the patch which implements the >> coordinator functionality. We don't need to change any other code or the >> caching implementation >> >>> >>> 1. >>> >>> Thank you & Best regards, >>> >>> *Amal Gunatilake* >>> Software Engineer >>> WSO2 Inc.; http://wso2.com >>> lean.enterprise.middleware >>> >> >> >> >> -- >> *Afkham Azeez* >> Director of Architecture; WSO2, Inc.; http://wso2.com >> Member; Apache Software Foundation; http://www.apache.org/ >> * <http://www.apache.org/>* >> *email: **[email protected]* <[email protected]> >> * cell: +94 77 3320919 <%2B94%2077%203320919> blog: * >> *http://blog.afkham.org* <http://blog.afkham.org> >> *twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez> >> * linked-in: **http://lk.linkedin.com/in/afkhamazeez >> <http://lk.linkedin.com/in/afkhamazeez>* >> >> *Lean . Enterprise . Middleware* >> >> _______________________________________________ >> Dev mailing list >> [email protected] >> http://wso2.org/cgi-bin/mailman/listinfo/dev >> >> > > > -- > Sagara Gunathunga > > Senior Technical Lead; WSO2, Inc.; http://wso2.com > V.P Apache Web Services; http://ws.apache.org/ > Linkedin; http://www.linkedin.com/in/ssagara > Blog ; http://ssagara.blogspot.com > > > _______________________________________________ > Dev mailing list > [email protected] > http://wso2.org/cgi-bin/mailman/listinfo/dev > > -- *[image: http://wso2.com] <http://wso2.com> Senaka Fernando* Senior Technical Lead; WSO2 Inc.; http://wso2.com * Member; Apache Software Foundation; http://apache.org <http://apache.org>E-mail: senaka AT wso2.com <http://wso2.com>**P: +1 408 754 7388; ext: 51736*; *M: +94 77 322 1818 Linked-In: http://linkedin.com/in/senakafernando <http://linkedin.com/in/senakafernando>*Lean . Enterprise . Middleware
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
