According to the docs for infinispan: http://docs.jboss.org/infinispan/5.0/apidocs/ the evict() API does not remove the entry from any other cache stores in the cluster, on the cache store it was invoked on.
If using "replication" mode, where the data is replicated across the caches, surely it has to be consisted and using the evict() API will make it inconsistent.
How then is the inconsistency resolved?
Thanks
Evict removes the entry only from the memory on the node where you call it. It does not make the cache inconsistent, because if you call cache.get() and the entry is not found in memory, it is loaded from cache store.
As the documentation states, the purpose is to inform cache that it won't use the entry for some time and the node can free some memory.
Related
When using BinaryObject for off-heap in-memory-only cache values, do we need to do anything to protect against the cache entry being evicted or expired while accessing fields via BinaryObject::field(String)?
For example, if the cache's data region has the default memory-size eviction (90% full?), or if the cache uses a creation expiry policy, and the region happens to evict entries or the cache expire entries while the code is making several calls to BinaryObject::field(String). Does Ignite automatically ensure that BinaryObject won't access invalid off-heap memory (throwing an exception perhaps), or can the developer use locking / transactions or a "touched" expiry to help prevent this?
Thanks!
BinaryObject instances returned from the Ignite API and accessed by the user code are copies. They do not reference Ignite storage memory directly.
You can work with BinaryObject even after the corresponding cache entry gets evicted.
When a cache object becomes eligible for eviction, it will be removed from memory.
Ignite has several Eviction policies:
Random-LRU
Random-2-LRU
Explained here
This means that if you recently used a cache value(or are using it at the moment that the eviction is taking place), either in BinaryObject representation or not, it will not be evicted. All Eviction algorithms use a LEAST RECENTLY USED algorithm.
I am using embedded Infinispan 10.1.8 and I have a clustered cache in INVALIDATION_SYNC mode. The cache is backed by another data store which is rarely updated which is why it's in that mode.
When a server leaves the cluster, Infinispan logs a message like this:
[Context=<cache name>] ISPN000312: Lost data because of graceful leaver <address>
Whatever was in the cache on that server is lost from memory, but since it is an invalidation cache I don't see why this would be a warning.
Is the warning unnecessary, or am I misunderstanding something about how this caching works?
I think the warning in invalidation mode only makes sense when you use the mode in a way that does not make sense.
This cache mode only makes sense if you have another, permanent store for your data such as a database and are only using Infinispan as an optimization in a read-heavy system, to prevent hitting the database for every read.
Source: https://infinispan.org/docs/dev/titles/configuring/configuring.html#invalidation-configuring
When you have such a permanent store, you effectively just loose the information in what state the cache was regarding the "lost" but easily recoverable segment.
The warning is always logged when a cache segment is not backed by any node anymore:
https://github.com/infinispan/infinispan/blob/10.1.8.Final/core/src/main/java/org/infinispan/partitionhandling/impl/PreferAvailabilityStrategy.java#L54
https://github.com/infinispan/infinispan/blob/10.1.8.Final/core/src/main/java/org/infinispan/topology/ClusterTopologyManagerImpl.java#L785
When you use a replicated cache that is not backed by a permanent store, you really loose data. I can't think of a situation where the warning makes sense in invalidation mode. I think in this case the warning should be removed because it is irritating.
I have two questions regarding the reddison client:
Does redisson support automatic synchronization of local cache with remote redis cache (when remote cache data change or invalidate)?
I understand that redisson supports data partitioning only in pro edition but isn't that feature already supported OOTB by redis cluster mode? Am I missing something here?
Answering to your questions:
RLocalCachedMap has two synchronization strategies:
INVALIDATE - Used by default. Invalidate cache entry across all RLocalCachedMap instances on map entry change.
UPDATE - Update cache entry across all LocalCachedMap instances on map entry change.
Right, all Redisson objects works also in cluster mode. Each object tied to some Redis node and its content always remain only on the same Redis node and not distributed. If your object couldn't fit in single Redis node then you need to use data partitioning feature. This feature evenly distributes content of object across multiple Redis nodes in cluster.
Re: "local cache truely local" -- I think you can just use a java Map, initially populate it with a RMap contents then from then on just serve your requests from the 'truely local' map in memory.
If I am using EclipseLink for entity cache or named query cache with a timeout, I suppose it will not be automatically removed when the cache is timed out in order to save memory. Does it?
If I have a memory problem like Heap memory is at critical level, will EclipseLink cache be automatically removed (does it use WeakReference or similar mechanism to manage cache map instead of strong reference) ?
Thanks,
EclipseLink has both an identity map and cache at the factory level, allowing a set cache size and an expensive identity map that allows for garbage collection. The documentation explains it and the options available to control or disable it depending on your application needs
Consider a Infinispan cache ( version 5.3.0.Final) Which having following properties,
Have file store
Passivation is set to true.
I have following problems when understanding the cache behavior.
Is there two threads for eviction and expiration ?
When expiration thread runs, what happens to entries which are in file, but has expired ? Do those load back to memory and removed ?
What is time duration for these threads to run ?
Does the file store file is append-only file ?
Does file has a index in this Infinispan version ?
What exactly stored in file in this Infinispan version ? Is it key-value or just value ?
I won't speak about such an old version, but it's likely the same.
The naming is a bit messy, TBH. There's threadpool with id org.infinispan.executors.eviction with single thread by default, which hosts ScheduledTask that processes expiration. Eviction is triggered only when you add something to the data container, and it is processed by the thread that added the new item.
Depends on cache store implementation - cachestore SPI has method purgeExpired() which forces removal of expired entries from the store. Nothing needs to be loaded into memory.
By default it's 1 minute. Search for wakeUpInterval (or wake-up-interval) in configuration.
No, none of the classical file stores. SoftIndexFileStore uses similar technique.
FileCacheStore has just several 'buckets' and is based on key hashCode, SingleFileCacheStore (or KarstenFileCacheStore, depends on your version) has in-memory index.
Both keys and values.