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.
Related
Expiry policy on off-heap entries is not working as expected. I am seeing a linear increase in off-heap entries and after some time sudden dip in off-heap size. Is only marking of cache entry done after expiry time and collected later in bulk? I am not finding any documentation regarding the same.
We need to enable eager TTL in the cache configuration. It will create a thread in the background and removes the expired entries.
There are two modes of expiry policy in Ignite: eager and non-eager: https://www.gridgain.com/docs/latest/developers-guide/configuring-caches/expiry-policies#eager-ttl
In case of an eager TTL entries are expired periodically by a background thread. When a non-eager TTL is used, then entries are only expired upon access. So, it's possible for expired entries to be stored in off-heap for some time until they get read.
Also keep in mind that JVM can allocate more memory than is immediately required. The amount of memory allocated by the Java process is not directly related to the amount of data stored in Ignite.
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
I have a redis cache in Azure with maxmemory policy set as Volatile-LRU. When writing to Redis, I am not adding an expiry time for the key. In this case, what will happen when the cache memory get filled?
Under the volatile-lru policy, redis will never evict a key without a expiry. If all of memory is used up by keys that do not have expiry set then the next time you use a command that requires allocating more memory than is available, say SET, the command will fail and you will get this error message:
OOM command not allowed when used memory > 'maxmemory'
You will still be able to use commands that don't allocate memory, like GET. If you get your database into this state, you can use the EXPIRE command to set and expiry time on keys after the fact.
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.
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.