Hi Amal, It would be better if you can send detailed architecture to mailing list so that it will get wider attention and more comments.
Thanks ! On Mon, Apr 7, 2014 at 8:31 AM, Afkham Azeez <[email protected]> wrote: > 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 <%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* > -- 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
