Callback function for LifeWindow

[jgheewala]

Hi,

I have a requirement, that when an entry is marked for eviction (LifeWindow) I want to call a callback function before it gets evicted (essentially CleanWindow). Was looking at the config object and found out that callbacks are only supported for evictions.

Can you please share details on whether this can be supported or not?

[cristaloleg]

Hi, can you describe your goal more detailed? What is the point to have a callback before marking entry for eviction? or do you want to call callback after marking such entry? BTW, are you interested in changing entry status? (evict/no evict). Thanks.

[jgheewala]

Hi,

So the requirement is as follows:

entries: (k1, v1) (k2, v2) ... (kn, vn)

example 1: config: lifewindow: 10mins cleanwindow: 0

lifeWindowCb : func () { do something for the entry which got marked as dead}

example 2: config: lifewindow: 10mins cleanwindow: 15mins

lifewindowCb: func() { // do refresh for the entry which got marked ad dead} cleanwindowCb: func() {// update stats for the entry which are deleted and getting evicted}

What is the point to have a callback before marking entry for eviction? or do you want to call callback after marking such entry? [jgheewala]: so i want to register callback function for the entries that are marked as dead. The use can be thought of something as http session, where a session which is marked as dead but not evicted can be refreshed before it gets evicted

[cristaloleg]

@janisz any comments?

[janisz]

I think we can add new callback

[jgheewala]

Thanks a lot 😊

[janisz]

@jgheewala wyould you like to create a PR with this change? It should be pretty straight forward

[jgheewala]

@janisz sure i will send PR, when i have the code ready.

[btiernay]

@jgheewala Wanted to follow back up here to see if you had made any progress in this PR.

[btiernay]

@cristaloleg

BTW, are you interested in changing entry status? (evict/no evict).

This is our use case. i.e. using BigCache as a read through cache, we would like to disable / extend cache eviction if / when the upstream becomes unavailable to help extend HA semantics. I'm wondering if something can be done in the callback to allow for this use case. Thoughts?

[cristaloleg]

@btiernay well, theoretically callback can be like:

type OnEvictFn func(key, value []byte, reason RemoveReason) RemoveReason 

And when your upstream is not available this callback will always return NoEvict reason (we don't have it now but probably it can be added). Yeah, looks like it's not "on/post evict callback" but "pre evict callback".

@janisz better ideas?

[btiernay]

@cristaloleg I like this idea. Although my concern is that this would cause cache eviction thrashing when all keys start to expire. Thus it seems like being able to set the new TTL would be useful to avoid that. Thoughts?

[cristaloleg]

type OnEvictFn func(key, value []byte, reason RemoveReason) (RemoveReason, time.Duration)

? and returned duration is ignored only for NoEvict (feels like a magic a bit, not sure, maybe it's better to update key ttl manually? or disable eviction at all, hm)

[btiernay]

Your signature above was similar to what I was thinking, except maybe adding in the original TTL might be useful.

feels like a magic a bit, not sure,

Well, it is flexible and it is opt in-behavior so maybe that's acceptable?

maybe it's better to update key ttl manually?

Unfortunately, that's not possible because it requires a write lock to perform that operation in user code, which would lead to deadlock, correct? That is why having the semantics baked into the library seems necessary / safer.

or disable eviction at all, hm

That's possible, but will result in a thundering herd when it is "enabled" again. That's why reseting / extending the TTL seems more desirable.

[btiernay]

@janisz Any strong opinions or guidance here?