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: [email protected]
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 <[email protected]>
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: [email protected] <[email protected]>
> 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
> [email protected]
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
