Why does cacheShard.set call onEvict? about bigcache HOT 7 OPEN

Thanks for the feedback @isiddi4.

IIRC the original use case for better eviction support was fairly limited, so if you have a use case which extends or clarifies that reason, I'm happy to review anything you want to come up with. :)

from bigcache.

Sorry for the late response @mxplusb and thanks for the quick reply.

Essentially I have some code like this in my use case:

config := bigcache.Config{
    // some options here
    OnRemoveWithReason: func(key string, val []byte, reason bigcache.RemoveReason) {
        if reason == bigcache.Delete {
            return
        }
        if reason == bigcache.NoSpace {
            manageState() // don't need sync.Mutex here since this can only be called by set
        }
        if reason == bigcache.Expired {
            lock.Lock()
            manageState() // need locks here since this can be called by the cleanUp goroutine
            lock.Unlock()
        }
    },
}

// some other code

for {
    lock.Lock()
    // some code here that changes state
    cache.Set(someKey, someVal)
    // some code here that changes state
    lock.Unlock()
}

As its possible for set to call OnRemoveWithReason with reason "Expired", it's possible for the program itself to hang as locks cannot be reacquired in go.

from bigcache.

Thanks for your potential use case. I have some questions, mostly so I understand the context.

Looking at your OnRemoveReason, that makes sense, you'd want to handle state changes based on the reason so it doesn't affect downstream dependencies.

Bigcache locks internally for it's state changes, so I wouldn't worry about locking the cache. You'll also take a massive performance hit as well as block any readers, so I really wouldn't recommend that course of action.

Outstanding questions:

• Why do you want to lock the cache to handle eviction state changes?
• For eviction reasons that are not NoSpace, what is the reason for not updating the cache item asynchronously?
• Are you looking to lock the cache because you need more visibility into the internal locking mechanisms?
• If we were to expose the internal locking mechanisms, does that bring value to you?

from bigcache.

In order to answer your questions, I'll have to provide more context. This will be long so please bear with me.

I'm currently in the process of developing a network cache (cache service) for server streaming RPCs.
In otherwords, a client will send a request x, and will recieve responses x1, x2, x3,...xn via a pipe (x1 will come first, then x2, then x3,...)
I want to "grow" the entries in the cache as the responses come in.

Example cache service flow:
client sends request x
cache service looks up x in bigcache
cache miss
cache service requests responses from server
init some "wait list" to keep track of other clients that request x
cache service recieves x1
bigcache: (key: x, val: x1)
cache service recieves x2
bigcache: (key: x, val: x1x2)
.
.
.
cache service recieves xn
bigcache: (key: x, val: x1x2....xn)
satisfy all clients on "wait list"

There is a glaring issue with the above example: What if some entry (key: x, val: x1...xk) is too large to be set?
My solution was to first delete the entry, partially satisfy clients on the wait list, then put them on a "flight list," that is, after xk+1 is received by the caching service, it will be sent directly to the clients on the flight list instead of being cached. We still need to maintain a wait list since other clients may request x.

We must also consider another complication: What if the cleanUp goroutine attempts to clear an entry that is "in the process" of being cached?
Ideally, I would like to be able to clearly identify when the cleanUp goroutine is evicting something from the cache. If I can, then I'll be able to migrate clients from the wait list to the flight list cleanly (this will require locking as the wait list and flight list are shared between the cleanUp goroutine and the primary goroutine).

I could also address this simply by setting the cleanwindow to 0 in the config and permanently disabling the cleanUp goroutine, but I would like to have it available.

I hope providing this context answers your questions. Let me know if you need anymore information or if something doesn't add up.

from bigcache.

@cristaloleg what are your thoughts on this?

What if the cleanUp goroutine attempts to clear an entry that is "in the process" of being cached?

IIRC you can't set and clear at the same time on the same key, we lock internally. That isn't transparent to the consumer, but that's how we handle state internally.

from bigcache.

I'm not so sure in a onEvict in Set.
This will add additional complexity to the Set.

@isiddi4 have you tried to decrease clean-up time limit?

from bigcache.

I'm currently handling this by simply disabling clean-up altogether (CleanWindow = 0)

from bigcache.