Replies: 4 comments 8 replies
-
|
Hi @RogerSep what you are suggesting is something I've in fact already thought about, and could be done. Let me know what you think, and I can certainly do them both to cover each scenario. Btw as I've said in the other issue I'm leaving right now for a 2 week vacation, so you'll have to wait a little bit. |
Beta Was this translation helpful? Give feedback.
-
|
Similar request in #66 . |
Beta Was this translation helpful? Give feedback.
-
|
Update: I'm currently exploring this. |
Beta Was this translation helpful? Give feedback.
-
|
Your config seems correct, except for a minor detail: the So, your config should be:
After 6 hours the first request coming in should trigger the loading of fresh data from the db, all while being able to use the old data for some more time. If you also configured a soft timeout, everything should stay fast too. So what you described is correct, and I would not expect it to expire after just 6 hours (and the existing tests, run against a real distributed cache, confirm this). What distributed cache are you using? Redis or something else? If you can create a minimal repro I would be happy to take a look. |
Beta Was this translation helpful? Give feedback.
-
|
@jodydonetti Sorry for the delay, but I finally got back to testing this. I was not able to reproduce, so I must have misunderstood something during my initial implementation and testing. What generally confused me the most, is that For comparison, we have been using CacheTower and it configures cache lifetime as So with
Repro (LINQPad script): async Task Main()
{
// Verify FusionCache behavior:
// - Start with empty cache
// - First GetOrSet() creates fresh value
// - Second GetOrSet() gets memcached value
// - Taking down source (throw exception in factory from now on)
// - Wait 3 seconds, for cache to become stale (but not expire)
// - Third GetOrSet() returns stale value from memcache, because factory throws
// - Clear memcache, to simulate new application instance starting up
// - Fourth GetOrSet() returns the same stale value, because Redis still has it cached. This mimics starting a new application, while the data source is down.
//
// Requires: Redis, update connection string if necessary.
var cacheEntryOptions = new FusionCacheEntryOptions {
Duration = TimeSpan.FromSeconds(2),
FailSafeMaxDuration = TimeSpan.FromSeconds(60),
IsFailSafeEnabled = true,
};
var redisConnectionString = "localhost:6379";
CultureInfo.CurrentCulture = CultureInfo.CurrentUICulture = CultureInfo.GetCultureInfo("en-US");
var log = Serilog.Log.Logger = new LoggerConfiguration()
// Use Debug level for FusionCache diagnostics.
//.MinimumLevel.Debug()
.MinimumLevel.Information()
.Enrich.FromLogContext()
.WriteTo.Console()
.CreateLogger();
var services = new ServiceCollection();
services.AddLogging(b => b.AddSerilog(log, dispose: true));
services.AddStackExchangeRedisCache(o => o.Configuration = redisConnectionString);
services.AddFusionCacheSystemTextJsonSerializer();
services.AddFusionCacheStackExchangeRedisBackplane(o => o.Configuration = redisConnectionString);
services.AddMemoryCache();
services.AddFusionCache(o => {
o.DefaultEntryOptions.IsFailSafeEnabled = true;
o.DefaultEntryOptions.FailSafeMaxDuration = TimeSpan.FromSeconds(10);
});
var sp = services.BuildServiceProvider();
var cache = sp.GetRequiredService<IFusionCache>();
var memCache = sp.GetRequiredService<IMemoryCache>();
log.Information("Configuration: Duration {Duration}, FailSafeMaxDuration {FailSafeMaxDuration}\n", cacheEntryOptions.Duration, cacheEntryOptions.FailSafeMaxDuration);
const string cacheKey = "myvalue";
bool isSourceDown = false;
int i = 0;
int factoryCount=0;
var sw = Stopwatch.StartNew();
async Task<Foo> GetOrSetAsync()
{
var cachedValue = await cache.GetOrSetAsync(cacheKey,
(ctx, ct) =>
{
log.Information($"[#{i} - {sw.Elapsed.TotalSeconds:N1} s] - Factory invoked");
return isSourceDown
? Task.FromException<Foo>(new Exception("Source is down"))
: Task.FromResult(new Foo(DateTimeOffset.Now, $"[Value {factoryCount++} at {sw.Elapsed.TotalSeconds:N1} s]"));
},
options: cacheEntryOptions);
return cachedValue;
}
void LogValue(Foo foo) => log.Information("Got {Age:N1}s old value with message {Message}", (DateTimeOffset.Now - foo.When).TotalSeconds, foo.Msg);
log.Information("Clear any previous cached value");
cache.Remove(cacheKey);
log.Information("");
log.Information("First GetOrSet(), should create fresh value");
var val = await GetOrSetAsync();
LogValue(val);
log.Information("");
log.Information("Second GetOrSet(), should get memcached value");
val = await GetOrSetAsync();
LogValue(val);
log.Information("");
log.Information("Taking down source");
log.Information("Waiting 3 seconds, for cache to become stale (but not expire)");
Thread.Sleep(3000);
log.Information("");
log.Information("Third GetOrSet() should return stale value, because factory throws");
isSourceDown = true;
val = await GetOrSetAsync();
LogValue(val);
log.Information("");
log.Information("Clear memcache, to simulate new application instance starting up");
var memcachedValue = memCache.Get(cacheKey).Dump("Memcache value");
if (memcachedValue == null) throw new InvalidOperationException("Expected memcache to have a value before clearing.");
memCache.Remove(cacheKey);
memcachedValue = memCache.Get(cacheKey).Dump("Memcache value");
if (memcachedValue != null) throw new InvalidOperationException("Memcached not removed");
log.Information("Fourth GetOrSet() should return the same stale value, because Redis still has it cached. This mimics starting a new application, while the data source is down.");
val = await GetOrSetAsync();
LogValue(val);
log.Information("");
}
public record Foo(DateTimeOffset When, string Msg);Output: |
Beta Was this translation helpful? Give feedback.
-
Exactly! Here's my rationale for that: normally you would start using FusionCache like any other cache, so the cache duration is "how much time this will be valid", normal stuff. Then you may start enabling extra features, like fail-safe: in that case duration still means "how much time this will be valid" but with the added pro that, in case something goes wrong, you can still use that data for some more time, instead of just getting an exception. From the "outside" (eg: as a user of FusionCache), duration always means the same: "for how much time this data will be valid". From the "inside" instead, without fail-safe the duration corresponds to the actual physical expiration (now + duration) whereas with fail-safe the duration becomes more a "logical duration", and the physical expiration becomes now + fail-safe max duration, just like you described: there's no way around that, because keeping the expiration the same in both cases means FusionCache would not have anything stale to return in case something bad happens. Given the fact that I see that more as an "internal detail", I thought it was more important to give precedence to FusionCache users, as in you should not change how you think about for how much something should be valid, you just keep doing what you were doing before enabling fail-safe. Does it make sense, at least as in how do I picture it? Maybe I can change the docs a little bit to make that clearer. Maybe I can add an extra block in the fail-safe docs, something like "Implementation details" or something like that, where I explain more clearly that enabling fail-safe changes the physical expiration in the caches (memory and distributed). What do you think?
CacheTower is a great lib! With both CacheTower and FusionCache you can specify just a duration, and after that time passes the data will be gone and the factory will try to refresh it. But then:
To me the big difference is that FusionCache can give you protection from factory errors and from slow factory executions, whereas with CacheTower, if the factory throw an error and/or takes too much time, you will not be protected by that. But again I'd like to repeat: I know CacheTower and think it's a great lib! One last thing: I thought about adding an extra feature to start refreshing cached data sooner, something like CacheTower
Ok so it's working correctly, did I get it right? Thanks for the discussion, I like when we can confront our ideas like this 💪 |
Beta Was this translation helpful? Give feedback.
-
|
Yes, everything is operating smoothly once we understood that
I follow your reasoning for thinking in terms of fail-safe and fail-safe durations, it does make sense, but even after 6 months of using this library I still find it a bit unintuitive. Our primary use case is cache with eager renewal, so it might be why the naming and configuration setup rubs me the wrong way. The above two bullet points is what stumbled me to begin with when first trying out the library, and in my humble opinion it adds unnecessary complexity. Tweaking the xmldoc texts for We built our own setup factory methods to make it more intuitive, for us at least. This follows the naming used by CacheTower, which I immediately understood. // With eager renewal. Fail-safe is enabled since staleAfter is configured.
var opts = new FusionCacheEntryOptions()
.ConfigureLifeTime(timeToLive: TimeSpan.FromHours(24),
staleAfter: TimeSpan.FromHours(6));
// Without eager renewal. Fail-safe is disabled because staleAfter is missing.
var opts = new FusionCacheEntryOptions()
.ConfigureLifeTime(timeToLive: TimeSpan.FromHours(24));/// <summary>
/// Extensions for configuring FusionCache.
/// </summary>
public static class FusionCacheEntryOptionsExtensions
{
/// <summary>
/// Configures FusionCache entry lifetimes based on <see cref="timeToLive" /> and optionally <see cref="staleAfter" /> for eager renewal.
/// </summary>
/// <param name="options">The options to change.</param>
/// <param name="timeToLive">How long it should live in the cache.</param>
/// <param name="staleAfter">How long until it is considered stale and should be renewed. Must be shorter than <see cref="timeToLive" />.</param>
/// <remarks>
/// FusionCache is not too intuitive to configure for eager renewal, since it has the concept of fail-safe mode, which affects how
/// <see cref="FusionCacheEntryOptions.Duration" /> works.
/// </remarks>
/// <returns>FusionCache entry options.</returns>
public static FusionCacheEntryOptions ConfigureLifeTime(this FusionCacheEntryOptions options, TimeSpan timeToLive, TimeSpan? staleAfter = null)
{
if (staleAfter is { } staleAfterNotNull)
{
// When fail-safe mode is enabled, Duration is changed to mean when the cache is considered stale, while FailSafeMaxDuration is when it expires.
options.IsFailSafeEnabled = true;
options.FailSafeMaxDuration = timeToLive;
options.Duration = staleAfterNotNull;
}
else
{
// Disable fail-safe mode if cache should be considered fresh until it expires, so FailSafeMaxDuration's default value does not have an effect.
options.IsFailSafeEnabled = false;
options.Duration = timeToLive;
}
return options;
}
/// <summary>
/// Configures FusionCache entry lifetimes based on <see cref="CacheSetup" />.
/// </summary>
/// <param name="options">The options to change.</param>
/// <param name="cacheSetup">The cache setup.</param>
/// <remarks>
/// FusionCache is not too intuitive to configure for eager renewal, since it has the concept of fail-safe mode, which affects how
/// <see cref="FusionCacheEntryOptions.Duration" /> works.
/// </remarks>
/// <returns>FusionCache entry options.</returns>
public static FusionCacheEntryOptions ConfigureLifeTime(this FusionCacheEntryOptions options, CacheSetup cacheSetup)
{
return ConfigureLifeTime(options, cacheSetup.TimeToLive, cacheSetup.StaleAfter);
}
} |
Beta Was this translation helpful? Give feedback.
-
|
Hi @angularsen and thank you very much for sharing your thoughts! If you have some time, please read it and let me know what you think. Thanks! |
Beta Was this translation helpful? Give feedback.
-
|
Hi @RogerSep , I've finally added support for a custom duration for the distributed cache ( This feature is included in the newly release v0.12.0. Hope this helps. |
Beta Was this translation helpful? Give feedback.
-
Hi! I'd like to have a different configuration for the duration of the in memory values than the ttl in redis. Is there a way around that?
The idea is that the memory cache refreshes more often than the redis cache, so if other node updates the value in the distributed cache, the memory one will only be stalled by the duration of the in memory configuration.
Thanks! :)
Beta Was this translation helpful? Give feedback.
All reactions