Skip to content
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

[FEATURE] ♾️ Handle Infinity #126

Closed
jodydonetti opened this issue Mar 12, 2023 · 2 comments
Closed

[FEATURE] ♾️ Handle Infinity #126

jodydonetti opened this issue Mar 12, 2023 · 2 comments
Assignees
Labels
bug Something isn't working enhancement New feature or request
Milestone

Comments

@jodydonetti
Copy link
Collaborator

jodydonetti commented Mar 12, 2023

Problem

Community member @suhrab kindly reported that when using TimeSpan.MaxValue as the Duration, an ArgumentOutOfRangeException is being thrown when instead it should have been handled.

This, in turn, made a pattern emerge with which for "never expiring cache entries" the common way to do it may be to just set the duration to TimeSpan.MaxValue.

This situation, although maybe not that frequent, should be better handled.

Solution

Setting the Duration to TimeSpan.MaxValue is a scenario that should be gracefully handled.
Also, other similar edge case scenarios should be handled, like:

  • setting the Duration to a value lower than TimeSpan.MaxValue but still such that, when added to the current UtcNow, will result in an ArgumentOutOfRangeException
  • all of the above, plus jittering: so that even if Duration + UtcNow is still below the max expiration, the thing would not throw when adding some jittering (if enabled)

On top of this it would be nice to add to FusionCacheEntryOptions a couple of methods like SetDurationInfinite() and SetDistributedCacheDurationInfinite().
This would:

  • help users in such scenarios, by having an official and uniform way to approach this need instead of, say, doing something like setting the Duration to 100 years or something like that;
  • allow some internal optimizations, since instead of having for example a Duration of 100 years which would still need to be added to UtcNow to calculate the actual expiration, FusionCache would recognize the user's intent for the Duration to be "logically infinite" and just set the expiration to the max possible value

Additional context

Nitpicking corner: the "infinite duration" would be for all intent and purposes, practically infinite. Having said that it cannot be of course literally infinite, but instead will be DateTimeOffset.MaxValue which in turn is Dec 31st 9999.
In the xml docs I'm putting something like this:

/// <summary>
/// Set the duration to be infinite, so it will never expire.
/// <strong>NOTE:</strong> the expiration will not be literally "infinite", but it will be set to <see cref="DateTimeOffset.MaxValue"/> which in turn is Dec 31st 9999 which, I mean, c'mon. If that time will come and you'll have some problems feel free to try and contact me :-)
/// </summary>

I know, but still better to specify that 😅.

@jodydonetti jodydonetti added bug Something isn't working enhancement New feature or request labels Mar 12, 2023
@jodydonetti jodydonetti added this to the v0.20.0 milestone Mar 12, 2023
@jodydonetti jodydonetti self-assigned this Mar 12, 2023
@jodydonetti jodydonetti pinned this issue Mar 12, 2023
@jodydonetti jodydonetti changed the title [FEATURE] 🌌 Infinite Duration [FEATURE] 🌌 Handle Infinity Mar 12, 2023
@jodydonetti jodydonetti changed the title [FEATURE] 🌌 Handle Infinity [FEATURE] ♾️ Handle Infinity Mar 13, 2023
@jodydonetti
Copy link
Collaborator Author

Hi all, I just release v0.20.0-preview2 🎉

Unless some problems will came up this week, the next weekend I'll release the final v0.20.0.

@jodydonetti
Copy link
Collaborator Author

Hi everyone, I've finally released the new v0.20.0 🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant