blendle / object-cache Goto Github PK

See https://github.com/blendle/object-cache/blob/master/lib/object/cache.rb#L63-L65.

There's extra yield statements in these rescue blocks. When a cache backend goes down or the initial yield itself throws an error it means that code is executed twice which will impact performance, or worse, will have unwanted side-effects.

Hi I'd like to use this library but wondering if it's still in a usable state with Ruby 3 and actively maintained. Last commit is 2 years ago, thus my concern.

The use of Marshal.load poses a security risk. It could lead to remote code execution when loading untrusted data. I don't think it is not beyond the realm of possibilities that for some reason some program or piece of code manages to update data stored at 'object-cache'-defined keys, which in turn is deserialised by 'object-cache' (and thus Marshal.load).

As far as I can tell this library only supports the serialisation and deserialisation of simple types, which means it is probably as easy as replacing Marshal with a JSON serialiser?

Currently this gem allows values to be cached until the expire, when this happens a new value is generated, cached and returned. This means that every ttl one user/client/connection needs to wait for the cache to refresh.

It would be great if you could specify the time after which a value is stale (time to stale?). Where stale means the value can still be used but a new version should be generated in the background.

Ex:

def get_highscore
  Cache.new(tts: 5.minutes, ttl: 10.minutes) {
    get_resource('https://example.org/api/highscore.json')
  }
end

# snip…snip…snip

puts get_highscore # first time, fetches data

sleep 1.minute
puts get_highscore # use cache

sleep 5.minutes
puts get_highscore # cache is stale, method returns immediately background job fetches new data
puts get_highscore # background job might still be busy, stale cache still used, no second job started

sleep 5.seconds
puts get_highscore # new data is used, timers reset

sleep 15.minutes
puts get_highscore # value completely expired, method blocks to fetch new data.

This way values are kept up-to-date and no user/client/connection has is blocked every once and a while.

Two more ideas:

• Pluggable backend, defaulting to Thread.new. If this gem is used in an eventmachine environment eventmachine should be used.
• Automatic stale. If you measure the average time a refresh takes, you can predict when a new version should be fetch. ex: tts = ttl - (measured_time*2) (this should be disabled by default).

Cheers,
—Koen

Nice one @JeanMertz!

It will be shared in our next RedisWeekly!

Could not find proper tests for this scenario