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

Support TTL and reloadData #43

Closed
tuanpavn opened this issue Sep 17, 2019 · 15 comments
Closed

Support TTL and reloadData #43

tuanpavn opened this issue Sep 17, 2019 · 15 comments
Assignees
Labels
kind/enhancement Something could be better.
Milestone

Comments

@tuanpavn
Copy link

Please add TTL and loadData function into config so it can auto reload an item if it is expired.

@karlmcguire karlmcguire added the kind/enhancement Something could be better. label Sep 17, 2019
@barkanido
Copy link

Ttl eviction is highly valuable!

@karlmcguire karlmcguire self-assigned this Sep 22, 2019
@karlmcguire karlmcguire added this to the future milestone Sep 22, 2019
@manishrjain
Copy link
Contributor

We can do TTL based expiry. But load on TTL seems like a cumbersome design.

@barkanido
Copy link

Agreed, just invalidate items due to TTL and let the client decide.

@songboyu
Copy link

hello, could I ask when would you plan to add the ttl feature? I think it is necessary

@MarcSky
Copy link

MarcSky commented Oct 25, 2019

Yes we need ttl

@MarcSky
Copy link

MarcSky commented Oct 25, 2019

For example, I want than 1 key living 10second and after reload

@karlmcguire
Copy link
Contributor

Will be working on this over the next few days.

@karlmcguire karlmcguire modified the milestones: future, 1.1.0 Oct 25, 2019
@karlmcguire karlmcguire mentioned this issue Nov 15, 2019
@caofengl
Copy link

caofengl commented Dec 8, 2019

Will be working on this over the next few days.
May I ask when the master can join the ttl function?

@momilo
Copy link

momilo commented Dec 14, 2019

If I may join the discussion... It might be worth considering adding automated purging of expired items.

Ristretto currently seems to be focusing on a scenario where there is a huge amount of data, only a portion of which can be stored in pre-defined size of cache, and it is stored forever (i.e. MaxCost is reached quickly; some additional keys are tracked - NumCounters).

However, many use-cases require a TTL-driven cache, whereby you have to / are happy to cache everything as long as ... e.g. it is max 5 minutes old (e.g. for operations which tend to always be resolved within 1-2 minutes). Hence you would expect the MaxCost to be large (just in case ever needed) but the average cache size would be minimal. A go routine checking expiry times and deleting entries would be needed - and highly appreciated.

I would be happy to help with coding this. Currently it seems like karlmcguire and caofengl are already on it, but feel free to reach out to me if some extra help is needed.

@barkanido
Copy link

I think this was the original intent. wasn't it?

@momilo
Copy link

momilo commented Dec 15, 2019

My understanding was that the original intention was to merely add TTL as an eviction criterion, i.e. to remove expired items only when, and only to the extent that a space needs to be made for, a new item. But if a routine cleanup is already being considered then great.

@barkanido
Copy link

@karlmcguire any update on this?

@martinmr
Copy link
Contributor

@barkanido This was just merged recently. See PR #122

@martinmr
Copy link
Contributor

Re-opening since only the TTL part is done. I am not sure what the status of the reload function is.

@martinmr martinmr reopened this Jan 29, 2020
@martinmr
Copy link
Contributor

Just noticed that Manish didn't agree with the need of a reload function. I think it's a bad idea too. If you need to reload an item immediately after it's expired the client should handle it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/enhancement Something could be better.
Development

No branches or pull requests

9 participants