Hi Danesh, On Thu, Oct 22, 2015 at 9:11 AM, Danesh Kuruppu <[email protected]> wrote:
> Hi Rajith, > > +1 for approach. This fix will also address the issue [1]. > Could not verify whether this is the root cause for the above issue. The issue remains the same even after introducing the new cache instance. The cause of the issue needs to be identified. Apart from the workaround provided in the jira, this can also be avoided by log in from the other node after few minutes creating the tenant. > > One more suggestion, > > Shall we make only the mounted registry goes to the distributed cache. > rather storing both config and governance registry. IMO we need distributed > cache only for the mounted registries. for example. If we mounted only the > governance registry. we need to enable distribute cache only for the > governance registry. We can keep our config registry also in local cache. > > Any thoughts on this please. > +1 for the idea. Since target mount path can be defined in numerous ways (for ex: /_system/governance can be mounted to /_system/governance/dev or /_system/nodes) then resources in those paths only will be distributed. > > Thanks > Danesh > > 1. https://wso2.org/jira/browse/CARBON-14224 > > On Tue, Oct 20, 2015 at 7:59 PM, Rajith Roshan <[email protected]> wrote: > >> Hi all, >> >> *Problem* >> >> The Registry space provided to each product contains three major >> partitions. >> >> - *Local Repository* : Used to store configuration and run time data >> that is local to the server. This partition is not to be shared with >> multiple servers and can be browsed under /_system/local in the registry >> browser. >> - *Configuration Repository* : Used to store product-specific >> configuration. This partition can be shared across multiple instances of >> the same product. (eg: sharing G-Reg configuration across a G-Reg cluster) >> and can be browsed under /_system/config in the registry browser. >> - *Governance Repository* : Used to store configuration and data that >> are shared across the whole platform. This typically includes services, >> service descriptions, endpoints or data sources and can be browsed under >> /_system/governance in the registry browser. >> >> >> Currently all the resources to be stored in Local, Config, and Governance >> registry paths are stored in a single cache instance (with cache id : >> REG_CACHE_BACKED_ID). >> >> When clustering is enabled for a node this cache switch to distributed >> mode and this results in a distributed Local registry path, which is not >> the recommended behavior (Local registry path should not be shared with >> other nodes). >> >> >> *Proposed Solution* >> >> Implement two cache instances to store the registry resources. >> >> 1. Local cache - All the resources that are not stored in the sub >> directories of the "/_System/config" and "/_System/governance" are stored >> in this cache. This cache instance will not be switched to distributed >> mode >> in a clustered setup. >> 2. Distributed cache - This cache will store all the resources under >> the root directories of "/_System/config" and "/_System/governance". This >> cache instance will be switched to distributed mode in a clustered setup. >> >> >> Thanks! >> Rajith >> >> -- >> Rajith Roshan >> Software Engineer, WSO2 Inc. >> Mobile: +94-72-642-8350 <%2B94-71-554-8430> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > > Danesh Kuruppu > Software Engineer > WSO2 Inc, > Mobile: +94 (77) 1690552 > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > Thanks! Rajith -- Rajith Roshan Software Engineer, WSO2 Inc. Mobile: +94-72-642-8350 <%2B94-71-554-8430>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
