On Fri, Jul 20, 2012 at 2:30 PM, Subash Chaturanga <[email protected]> wrote:
> > > On Fri, Jul 20, 2012 at 2:17 PM, Tharindu Mathew <[email protected]>wrote: > >> Alright, so it worked earlier cus caching was not there at the registry >> API level? > > > Yes Tharindu you are quite right. > > Earlier (may be in our internship period time ;-) ) greg did not have > registry API level caching and now registry calls intercepted by a registry > called CacheBackedRegistry. And those days as there is no cache, no need > replicated caching enabled as both ends directly deals with the DBs. > How is the performance with replicated caching in a mounted scenario like this compared to the non cached mounted scenario? I hope not having a cache with jdbc mounting was not faster, although it could have been a conscious decision made during your intern time for faster performance ;) > >> >> On Fri, Jul 20, 2012 at 2:14 PM, Subash Chaturanga <[email protected]>wrote: >> >>> >>> >>> On Fri, Jul 20, 2012 at 1:19 PM, Tharindu Mathew <[email protected]>wrote: >>> >>>> There is no ESB cluster here. Only an ESB connecting to G-Reg. I >>>> believe for this scenario, replicated caching is not needed? >>> >>> Yes, I also didn't meant ESB cluster(may be I have not communicated it >>> ;-) ). I am also talking about a typical mounted scenario, i.e 1 esb, 1 >>> greg, esb gov mounted to greg gov and etc. And AFAIU the scenario I >>> explained is valid for such mounts. >>> >>> >>> >>>> >>>> >>>> On Fri, Jul 20, 2012 at 12:36 PM, Subash Chaturanga <[email protected]>wrote: >>>> >>>>> >>>>> >>>>> On Fri, Jul 20, 2012 at 10:36 AM, Tharindu Mathew >>>>> <[email protected]>wrote: >>>>> >>>>>> Subash, >>>>>> >>>>>> Can I know why this is needed? This was not required earlier so I'd >>>>>> like to understand why it's needed now? >>>>>> >>>>> >>>>> Hi Tharidu, >>>>> I hope you meant why caching a must for jdbc mounting. I am not sure >>>>> why this didn't wanted earlier. >>>>> >>>>> In caching of carbon clusters, each carbon instance has its own cache. >>>>> Assume replicated caching not enabled. >>>>> >>>>> So suppose a two node cluster which has jdbc mount. When do a update >>>>> on one carbon instance and it clears the cache and persist the >>>>> change(delete/put) to the DB. The problem comes when some other node do a >>>>> *get* from the same earlier changed location. Because its cache not >>>>> updated. Unless you do a put on the same location and clears the cache you >>>>> will not see the changes. If replicated caching enabled, infinispan does >>>>> the sync between two caches. >>>>> >>>>> >>>>> Hi Charitha, >>>>> In fact this is a MUST for atom/ws as well IF you need 100% >>>>> consistency across the cluster. Because there are some edge cases. >>>>> It works fine until you do changes from the mounted side. If you do >>>>> some changes on the other side(master), the changes not get reflected. I >>>>> hope you got what I meant. >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>> On Fri, Jul 20, 2012 at 9:49 AM, Charitha Kankanamge < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Thanks Subash, this is something we have not documented anywhere. We >>>>>>> should update all docs, blogs with this information. >>>>>>> >>>>>>> >>>>>>> On Friday, July 20, 2012, Subash Chaturanga wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Jul 19, 2012 at 11:48 PM, Charitha Kankanamge < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> Folks, >>>>>>>>> Should replicated caching be enabled with registry mounting? >>>>>>>>> Suppose /_system/governance space of an ESB instance is mounted (jdbc >>>>>>>>> or >>>>>>>>> ws) to the same collection of a central G-reg. In that case, should we >>>>>>>>> enable replicated caching in both ESB and G-reg instances? >>>>>>>>> Please confirm. >>>>>>>>> >>>>>>>> Hi Charitha, >>>>>>>> Yes, for JDBC mounting it is a MUST. But AFAIK, for atom/ws >>>>>>>> mounting it should be fine without replicated caching enabled. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> Charitha >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Dev mailing list >>>>>>>>> [email protected] >>>>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> Subash Chaturanga >>>>>>>> Software Engineer >>>>>>>> WSO2 Inc. http://wso2.com >>>>>>>> >>>>>>>> email - [email protected] >>>>>>>> phone - 077 2225922 >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Charitha Kankanamge >>>>>>> cell: +94 718 359 265 >>>>>>> blog: http://charithaka.blogspot.com <http://wso2.com> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Dev mailing list >>>>>>> [email protected] >>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Regards, >>>>>> >>>>>> Tharindu >>>>>> >>>>>> blog: http://mackiemathew.com/ >>>>>> M: +94777759908 >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Subash Chaturanga >>>>> Software Engineer >>>>> WSO2 Inc. http://wso2.com >>>>> >>>>> email - [email protected] >>>>> phone - 077 2225922 >>>>> >>>>> >>>> >>>> >>>> -- >>>> Regards, >>>> >>>> Tharindu >>>> >>>> blog: http://mackiemathew.com/ >>>> M: +94777759908 >>>> >>>> >>> >>> >>> -- >>> >>> Subash Chaturanga >>> Software Engineer >>> WSO2 Inc. http://wso2.com >>> >>> email - [email protected] >>> phone - 077 2225922 >>> >>> >> >> >> -- >> Regards, >> >> Tharindu >> >> blog: http://mackiemathew.com/ >> M: +94777759908 >> >> > > > -- > > Subash Chaturanga > Software Engineer > WSO2 Inc. http://wso2.com > > email - [email protected] > phone - 077 2225922 > > -- Regards, Tharindu blog: http://mackiemathew.com/ M: +94777759908
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
