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/>* >
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
