Hi All, WSO2 Cache is designed designed as a shared in-memory cache at the first place. We have made some effort to make it "non-shared" local cache for limited cases. However there are few problems due to some of the historical design based on shared cache.
a) Cache is expired at [1]. The cache entry is not cleared if the entry is recently modified or accessed (depending on the configuration). This was right decision on the shared cache. But have problems when we have local cache. We need to implement absolute TTL on local cache (not done yet) b) All caches go through single cleanup task. Each cache can be initialized as ACCESSED or MODIFIED or none. None means each cache entry is removed after given cache timeout of the relevant cache. So, @Bhathiya Jayasekara <bhath...@wso2.com> >>But they are removed after the configured cache timeout (individually based on their lifespan) even when they are kept being used. That means the ACCESSED type expiry is not honored, I assume. Is my understanding wrong? If the cache is not initialized as ACCESSED, this this can happen. @Azeez Afkham <az...@wso2.com> >>I suppose this was a change suggested by Ruwan to ensure that even if an entry is in use, we don't keep it fresh forever and to forcefully remove it after a period of time. This was implemented to address a particular edge case. This was not implemented yet. I plan to implement this in next IAM release, as we are currently recommending local-cache for all IAM deployment with invalidation messages. Invalidation messages may become dead letter, thus we need TTL of local cache. [1] https://github.com/wso2/carbon-kernel/blob/4.5.x/core/javax.cache/src/main/java/org/wso2/carbon/caching/impl/CacheImpl.java#L941 Cheers, Ruwan A On Mon, Jun 24, 2019 at 9:11 AM Afkham Azeez <az...@wso2.com> wrote: > I suppose this was a change suggested by Ruwan to ensure that even if an > entry is in use, we don't keep it fresh forever and to forcefully remove it > after a period of time. This was implementated to address a particular edge > case. Ruwan should be able to give more details. > > On Mon, Jun 24, 2019, 12:53 AM Bhathiya Jayasekara <bhath...@wso2.com> > wrote: > >> Hi Azeez/Nuwan, >> >> On Fri, Jun 21, 2019 at 2:57 PM Afkham Azeez <az...@wso2.com> wrote: >> >>> An item can get removed from the cache for two reasons: >>> >>> 1. Cache expiry. >>> A task runs periodically and checks the last accessed time of each cache >>> entry and removes it if the entry has not been accessed for sometime >>> >> >> This is what I expected/assumed too. (i.e. if a particular cache entry is >> kept being used forever, it should never be removed from cache [plz correct >> me if my understanding of ACCESSED type expiry is wrong] ) And I also have >> noticed that in some caches (I don't remember where) it runs a forceful >> cache clean up task periodically to remove these never-removable cache >> entries time to time. So that was the other part of my >> expectation/assumption. >> >> However, I ran a few tests with APIM gateway cache[1] with just 2 tokens. >> But results don't reflect above. Each cache entry has its own lifespan. >> That's correct. But they are removed after the configured cache timeout >> (individually based on their lifespan) even when they are kept being used. >> That means the ACCESSED type expiry is not honored, I assume. Is my >> understanding wrong? >> >> [1] >> https://github.com/wso2/carbon-apimgt/blob/master/components/apimgt/org.wso2.carbon.apimgt.impl/src/main/java/org/wso2/carbon/apimgt/impl/utils/APIUtil.java#L7487 >> >> >> p.s. what does setStoreByValue mean in [1]? >> >> Thanks, >> Bhathiya >> >> >>> >>> 2. Cache eviction >>> When cache capacity is reached and there is no more space to insert >>> items, then 25% of the items are (forcefully) evicted (even if they have >>> not expired). >>> >>> If the cache is periodically purged even ignoring the above two cases, >>> then it is incorrect. Such code didn't exist in the early versions of >>> caching that I implemented. >>> >>> Azeez >>> >>> On Fri, Jun 21, 2019 at 12:07 PM Nuwan Dias <nuw...@wso2.com> wrote: >>> >>>> Hi, >>>> >>>> I have heard about two mechanisms how the cache expires in WSO2 >>>> products. >>>> >>>> 1. Each cache entry has its individual lifespan specified in the cache >>>> timeout config (15m by default). >>>> 2. A scheduled job that runs periodically (based on the cache timeout) >>>> cleans the full cache on each run. This would mean that some cache entries >>>> expire sooner than the others. >>>> >>>> Which of the above is correct? Or is it completely different? Can we >>>> alter between the two based on a config? >>>> >>>> Thanks, >>>> NuwanD. >>>> >>>> -- >>>> *Nuwan Dias* | Director | WSO2 Inc. >>>> (m) +94 777 775 729 | (e) nuw...@wso2.com >>>> [image: Signature.jpg] >>>> >>> >>> >>> -- >>> *Afkham Azeez* | Vice President | WSO2 Inc. >>> (m) +94773320919 | (w) +94117435800 | (e) az...@wso2.com >>> GET INTEGRATION AGILE >>> Integration Agility for Digitally Driven Business >>> >>> >> >> -- >> *Bhathiya Jayasekara* >> *Technical Lead,* >> *WSO2 inc., http://wso2.com <http://wso2.com>* >> >> *Phone: +94715478185* >> *LinkedIn: http://www.linkedin.com/in/bhathiyaj >> <http://www.linkedin.com/in/bhathiyaj>* >> *Twitter: https://twitter.com/bhathiyax <https://twitter.com/bhathiyax>* >> *Blog: http://movingaheadblog.blogspot.com >> <http://movingaheadblog.blogspot.com/>* >> > -- Ruwan Abeykoon | Director/Architect | WSO2 Inc. (w) +947435800 | Email: ruw...@wso2.com
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
