-
-
Notifications
You must be signed in to change notification settings - Fork 74
keepDataAfterExpired and loader exceptions #163
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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 |
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: