keepDataAfterExpired and loader exceptions #163
Comments
Yes! There is a whole chapter on it: https://cache2k.org/docs/latest/user-guide.html#resilience-and-exceptions Try setting
Are you speaking of one cache or is that multiple caches stacked together? Can you give some minimal code to reproduce that? |
Hmm, with more thought of it, I assume that you are accessing the previous entry in the cache loader. I am currently working on a 2.0 version. I recall that I found some inconsistencies in 1.4 and 1.6. If an exception occurred the advanced loader might get a null entry or an entry with exception. The latest code is consistent and you get an entry with exception information from the previous load. |
|
Unfortunately, I had read section 9 of the documentation and the behavior still remained unclear to me. There is mention of "Cached Exceptions", subsection header 9.7.4, but that refers to eternal entries. I did not mention in my original post that we have a custom Unfortunately, settings I will provide a code example first thing tomorrow! |
|
Also check your loader implementation. I assume that you do |
Probably because it would just prevent an exception being cached by expiring that entry immediately. However, with |
|
BTW, its good that you came up with this issue. Exception caching and resilience will not be enabled by default in 2.0 However, that would not make a difference in your situation using the |
@cruftex Sorry for not getting back to you sooner. The above quote was in fact the issue. It wasn't that my loader was throwing a RuntimeException continuously, it was that i was calling |
|
An example: package com.github.cache2k
import org.cache2k.Cache;
import org.cache2k.Cache2kBuilder;
import org.cache2k.CacheEntry;
import org.cache2k.integration.AdvancedCacheLoader;
import org.junit.Before;
import org.junit.Test;
public class Cache2kLoadFailure {
private Cache<String, String> testCache;
@Before
public void before() {
testCache = new Cache2kBuilder<String, String>() {}
.name("heap-exhaustion-cache")
.expiryPolicy((key, value, loadTime, oldEntry) -> 0)
.keepDataAfterExpired(true)
.refreshAhead(true)
.loader(new AdvancedCacheLoader<String, String>() {
@Override
public String load(String key, long startTime, CacheEntry<String, String> currentEntry) {
if(currentEntry != null) { // Entry will be null at first run. This fills the entry with an exception at first
// if(currentEntry.getException != null) fixes the issue
currentEntry.getValue();
}
throw new RuntimeException("Runtime exception");
}
})
.build();
}
@Test
public void failLoop() {
while(true) {
// increase the upper bound of this loop to exhaust the heap quicker
for(int i = 0; i < 100; i++) {
String key = "test" + i;
try {
testCache.get(key);
} catch(Exception e) {
}
}
}
}
} |
|
@rene-m-hernandez No worries. Thanks for the feedback! Using Ideas: Add behavior that detects a Maybe don't call the loader with an entry if the entry has an exception. Probably every loader would |
cruftex
changed the title
|
Delivered and released as preview: https://github.com/cache2k/cache2k/releases/tag/v1.9.2.Alpha |
After deploying cache2k with a loader that always threw an exception, we experienced an OOM.
We originally had set
keepDataAfterExpired=true(in combination withrefreshAhead=true), with the desire to allow stale data to remain in the cache. Java docs:Unfortunately, when this is true, Cache2k appears to cache exceptions, which was completely unexpected (is this clearly documented somewhere?) Additionally, the default ExceptionPropagator appends a message to the original exception. These two behaviors combined lead to a cache entry that is an ever-growing exception so long as the cache loader continues to fail, eventually causing OOM.
Is there anyway to prevent exceptions from being cached? Our two options appear to be:
keepDataAfterExpired=false(undesired), or provide a custom ExceptionPropagator that does not infinitely grow entries that contain exceptions.An example exception (stored in the cache as an entry) that continued to grow:
The text was updated successfully, but these errors were encountered: