Amal is creating a generic component which will expose a CacheInvalidator OSGi service. This service takes care of publishing to the cache invalidation topic. GReg & UM code would be the consumers of this service. The general caching code will not be aware of this implementation.
Azeez On Mon, Apr 7, 2014 at 11:56 AM, Senaka Fernando <[email protected]> wrote: > 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 <%2B1%20408%20754%207388>; ext: 51736*; > > > *M: +94 77 322 1818 <%2B94%2077%20322%201818> Linked-In: > http://linkedin.com/in/senakafernando > <http://linkedin.com/in/senakafernando>* > 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 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
