Hi all, On Sun, Jul 3, 2011 at 10:33 AM, Afkham Azeez <[email protected]> wrote:
> > > On Sun, Jul 3, 2011 at 8:15 AM, Sumedha Rubasinghe <[email protected]>wrote: > >> >> >> On Sat, Jul 2, 2011 at 8:26 PM, Afkham Azeez <[email protected]> wrote: >> >>> >>> Senaka >>> Shankar mentioned $subject. Isn't this sub-optimal? For instance, caching >>> will not reduce the load on the DB in the current implementation. Why has it >>> been implemented this way? >>> >> For the benefit of others who do not know the full context, >> >> Current distributed caching impl is local to a particular node. Whenever >> the first request for a resource is made, if it's not in the local cache , >> it gets added. This way there could be several caches of same resource local >> to different G-Reg instances. When that particular resource is modified >> through one G-Reg server, a message is being sent to other local caches to >> invalidate their cached copy. >> >> I think was done due to several reasons. >> - Replicating a large object over distributed cache being an over head >> - A resource has considerable amount of meta data around it (properties, >> associations/dependencies, tags, comments, etc). No clear decision on >> replicating those or not. >> - Collection & Resource not being serializable >> >> Technically, most of these issues can be solved easily. >> > No, this was not done not simply because of technical limitations, there were some pros in using the current model compared to what we are trying to achieve by replicating it. Replication itself is expensive and can be more expensive than a DB-fetch at times. >> I believe we should at least , >> - think of distribute caching resources bellow a certain size >> - Cache certain type of media types (eg. synapse-config, wsdls) which have >> more tendency to be accessed across cache >> >> > +1 > Agreed, but the gain is only the improvement in speed in making the first call in each node. But, for that to be effective, we need to use synchronous replication. Because, if you use asynchronous replication, the caches are that the subsequent nodes will also make DB calls before the replication completes. But, with synchronous replication, it will take a long time for the very first fetch in the very first node to complete. Also, I'd like to clear the doubts around what we have in place. Frequently accessed resources are cached at each node, until it gets invalidated. So, the gain of doing what we have above is only improving the speed of the first-call in a multi-node G-Reg deployment. Even in Stratos, this would become useful only if two nodes are serving a single-tenant. If a single tenant is restricted to a single-node, doing the above will actually reduce performance and increase memory consumption rather than providing any improvement. So, I'd like to discuss the pros and cons of doing the above before actually going ahead with it, only if there is any benefit of doing it. Thanks, Senaka. > >> /sumedha >> >> >>> ---- >>> Sent from my phone >>> >>> _______________________________________________ >>> Carbon-dev mailing list >>> [email protected] >>> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >>> >>> >> >> _______________________________________________ >> Carbon-dev mailing list >> [email protected] >> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >> >> > > > -- > *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* > * > * > *Lean . Enterprise . Middleware* > > > _______________________________________________ > Carbon-dev mailing list > [email protected] > http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev > > -- *Senaka Fernando* Product Manager - WSO2 Governance Registry; Associate Technical Lead; WSO2 Inc.; http://wso2.com* Member; Apache Software Foundation; http://apache.org E-mail: senaka AT wso2.com **P: +1 408 754 7388; ext: 51736*; *M: +94 77 322 1818 Linked-In: http://linkedin.com/in/senakafernando *Lean . Enterprise . Middleware
_______________________________________________ Carbon-dev mailing list [email protected] http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
