-
1. Re: Eviction and Infinispan as a second level cache provider
rvansa Jun 14, 2016 2:49 AM (in response to mjhaller)The limitation applies only to the caches in replication mode, which use tombstones. Default configuration has invalidation-mode caches with 10k entries, and this combination is safe.
I apologize if the blogpost is not clear in this matter (I'll reformulate it). The table on the bottom shows that eviction is allowed in invalidation mode.
-
2. Re: Eviction and Infinispan as a second level cache provider
mjhaller Jun 14, 2016 1:50 PM (in response to rvansa)I think the blog post is clear, especially that nice little table at the end. However, we are using replication, as seen below:
<?xml version="1.0" encoding="UTF-8"?> <infinispan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:infinispan:config:8.1 http://www.infinispan.org/schemas/infinispan-config-8.1.xsd urn:infinispan:config:store:jdbc:8.0 http://www.infinispan.org/schemas/infinispan-cachestore-jpa-config-8.0.xsd" xmlns="urn:infinispan:config:8.1"> <jgroups> <stack-file name="external-file" path="jgroups-l2cache.xml" /> </jgroups> <cache-container default-cache="default" statistics="true"> <transport stack="external-file" /> <distributed-cache-configuration name="entity" statistics="true" /> <distributed-cache-configuration name="distributed-query" statistics="true" /> </cache-container> </infinispan>
With this configuration it seems we must use EvictionStrategy.NONE, correct?
... <prop key="hibernate.cache.infinispan.eviction.strategy">NONE</prop> ...
-
3. Re: Eviction and Infinispan as a second level cache provider
rvansa Jun 15, 2016 3:17 AM (in response to mjhaller)The config you show uses distribution, and that means that the record in cache will have 2 copies (or 1 if there's single node). Replication will keep a copy on each node, therefore the reads will be local (as long as the entity is in the cache), with distributed cache, some reads cause RPC, and going to different node can be as slow as going to DB machine.
But yes, with both distributed and replicated caches, you have to disable eviction, either through hibernate properties as you suggest, or through configuration:
<distributed-cache-configuration name="entity">
<eviction strategy="NONE"/>
</distributed-cache-configuration>
Actually no eviction is the default, so unless you override it through hibernate properties, you configuration should not use eviction.
If you want to avoid having too many unused entities in the cache, you can set expiration and entries that are not read for a while will get purged out of the cache:
<distributed-cache-configuration name="entity">
<eviction strategy="NONE"/>
<expiration max-idle="3600000"/>
</distributed-cache-configuration>
Though, when you want to limit absolute number of entities, you have to tune the value according to you app's behaviour.
-
4. Re: Eviction and Infinispan as a second level cache provider
mjhaller Jun 23, 2016 5:06 PM (in response to rvansa)Thank you very much Radim. Just wanted to post the conclusion and say thanks:
We decided to go with the recommended invalidation mode. Here is our current config, which is working well:
<?xml version="1.0" encoding="UTF-8"?> <infinispan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:infinispan:config:8.1 http://www.infinispan.org/schemas/infinispan-config-8.1.xsd urn:infinispan:config:store:jdbc:8.0 http://www.infinispan.org/schemas/infinispan-cachestore-jpa-config-8.0.xsd" xmlns="urn:infinispan:config:8.1"> <jgroups> <stack-file name="external-file" path="jgroups-l2cache.xml" /> </jgroups> <cache-container default-cache="default" statistics="true"> <transport stack="external-file" /> <invalidation-cache-configuration name="entity"> <eviction strategy="LRU" max-entries="40000" /> </invalidation-cache-configuration> </cache-container> </infinispan>
We also enabled a query cache, but are still benchmarking that.