Hi Riyafa, I agree Guava caching implementation is much more improved than JCache. But recently the trend has shifted towards using Caffeine [1] as it supersedes the caching support in the Google Guava library with an actively maintained Java 8+ version in standalone form. Event Spring framework has shifted towards Caffeine from version 5.0 onwards [2].
- Has good performance[1] You have pointed the URL of caffeine. In that case, are you planning to use the Caffeine? [1] https://github.com/ben-manes/caffeine [2] https://jira.spring.io/browse/SPR-13797 Regards, Firzhan email: firz...@wso2.com mobile: (+94) 77 9785674 <%28%2B94%29%2071%205247551>*| blog: http://firzhanblogger.blogspot.com/ <http://firzhanblogger.blogspot.com/> <http://suhothayan.blogspot.com/>* *twitter: https://twitter.com/firzhan007 <https://twitter.com/firzhan007> | linked-in: **https://www.linkedin.com/in/firzhan <https://www.linkedin.com/in/firzhan>* On Sun, Nov 12, 2017 at 6:09 PM, Riyafa Abdul Hameed <riy...@wso2.com> wrote: > Hi, > > Currently we have used the guava cache for the cache mediator > implementation. The reason for choosing guava cache over kernel > implementation of jcache are as follows: > > > - *Main reason:* The guava cache implementation allows to specify a > maximum size which is the number of entries in the cache. > - Simple to use--does not have a close method > - Has good performance[1] > - Previous implementation of cache mediator using jcache > implementation of the cache mediator has several issues[2]. All the past > issues with cache mediator has been resolved in the rewrite and it has been > well tested. > - We are not supporting distributed caching in the cache mediator now > and the complicated implementation of jcache in the kernel with hazelcast > is no more needed. > > Note the following: > > - The cache mediator has already been implemented using guava cache > and shifting to jcache is additional work and would require more testing > - It is possible to argue that the maxsize implementation is already > available in the kernel implementation of jcache, but I would like to point > out that this implementation does not evict messages from the cache as soon > as maxSize is reached, but will wait for 30s before it checks the maxsize. > This is not what is expected from a cache mediator and using this would > mean that we have thread sleeps in all tests written and possible > complaints from future users. > - Current wso2 products already use guava cache because of the added > benefits. One example is andes[3]. > > [1] https://github.com/ben-manes/caffeine/wiki/Benchmarks > [2] https://wso2.org/jira/browse/ESBJAVA-5214 > > [3] https://github.com/wso2/andes/blob/9acf25bea2ec97cca389482381c93f > 3e1e3688d5/pom.xml#L195-L199 > > Thank you, > Riyafa > > > -- > Riyafa Abdul Hameed > Software Engineer, WSO2 Lanka (Pvt) Ltd <http://wso2.com/> > > Email: riy...@wso2.com <riyafa...@cse.mrt.ac.lk> > Website: https://riyafa.wordpress.com/ <http://riyafa.wordpress.com/> > <http://facebook.com/riyafa.ahf> <http://lk.linkedin.com/in/riyafa> > <http://twitter.com/Riyafa1> > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > >
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture