Low timeout loader function race about ttlcache HOT 2 CLOSED

Hello, i understand the issue and see that it can be fixed. I'd like to know what your usecase is though. The 'average' usecase i have in mind is caching network requests which would have a TTL of seconds or maybe high milliseconds. This mean that the described issue is not really a thing.

If you can describe what you are doing (probably some caching internal to the application) then it helps me to take better decisions for all users in the future.

Also reasoning about fast expiration: on the one hand i can defend the current behaviour by saying that if it takes >expirationTime to access the key that it would indeed be expired. On the other hand, if a key is retrieved and parked for further processing by GC/lock's later on i would consider it valid. Therefore the singleflight option looks good.

Please go ahead with the PR.

from ttlcache.

Thanks, I'll float a PR by you in a day or two.

I was mistaken in the first post, my use case actually had:

• A TTL of 5 seconds
• Somewhere in the range of 100-1000 requests per second per key across 10ish keys.
• The loaderfunction takes 5ms to execute on average, but maybe sometimes much longer when there are network issues.
• We are caching some mutable database state in our application, and should/could use a queue or similar instead of a cache but this was easy to implement and good enough!
• We have many worker nodes, each that cache some frequently used state.

I'm not convinced the reproduction fully explains why sometimes I get the error (my TTL is much higher), but it is the only logic path I could see where it seems possible! Maybe there's some other lock contention I'm not considering.

from ttlcache.