In the development environment I don't want async-cache to cache the object, so I set maxAge: 0. In fact, this value is automatically set by the application based on which environment it has been launched at (production vs. development).

However, for some reason when maxAge: 0, the cache never expires, and async-cache never updates the cache.

When I set 0 it should expire immediately.

Isaac,
The package.json file indicates the is BSD licensed. But if you want to choosealicense (.com) and then addalicense (.com) then it will add the license file explicitly. Or you can just copy a license file into the repo.

Here's why I'm suggesting this: we'd like to use this code and if we do use it in our app, we'd like to make sure to give you credit by pointing to your license file. Right now we can only point to the package.json file.

Just a heads up: I can't pinpoint exactly there this is happening, but in production on high traffic sites the cache is bleeding memory. Even with a small max(10-99), and small objects. I'm still looking into this issue.

A lot of times, there's some data that you want to keep reasonably fresh, but is a bit expensive to go fetch, like a view in a database or something that's unlikely to change more than once a day, but is a bit costly to fetch.

In those cases, it would sometimes be best to provide outdated information, but then go update in the background.

Add a stale: true flag on the options to tell asyncCache to behave this way.

I use async-sache to retrieve fs.stats().

var stats = new AsyncCache({
    max: 100,
    // 10 minutes
    maxAge:  1000 * 60 * 10,
    load: function (filePath, cb) {
        fs.stat(filePath, cb);
    }
})

When I call stats.get() for the 1st time I get the following result:

{ dev: 16777218,
  mode: 33188,
  nlink: 1,
  uid: 501,
  gid: 20,
  rdev: 0,
  blksize: 4096,
  ino: 25022425,
  size: 7207,
  blocks: 16,
  atime: Sun Jan 06 2013 21:37:10 GMT+0900 (KST),
  mtime: Fri Jan 04 2013 23:33:22 GMT+0900 (KST),
  ctime: Fri Jan 04 2013 23:33:22 GMT+0900 (KST) }

Notice mtime is a Date object pointing to Jan 04.

When I call stats.get() for the 2nd time (gets from cache), the mtime changes by adding 3 month: now it's Apr 04.

{ dev: 16777218,
  mode: 33188,
  nlink: 1,
  uid: 501,
  gid: 20,
  rdev: 0,
  blksize: 4096,
  ino: 25022425,
  size: 7207,
  blocks: 16,
  atime: Sun Jan 06 2013 21:57:12 GMT+0900 (KST),
  mtime: Thu Apr 04 2013 23:33:22 GMT+0900 (KST),
  ctime: Fri Jan 04 2013 23:33:22 GMT+0900 (KST) }

When I call stats.get() for the 3rd time (gets from cache), the mtime changes again by adding 3 month: now it's Jul 04.

{ dev: 16777218,
  mode: 33188,
  nlink: 1,
  uid: 501,
  gid: 20,
  rdev: 0,
  blksize: 4096,
  ino: 25022425,
  size: 7207,
  blocks: 16,
  atime: Sun Jan 06 2013 21:57:12 GMT+0900 (KST),
  mtime: Thu Jul 04 2013 23:33:22 GMT+0900 (KST),
  ctime: Fri Jan 04 2013 23:33:22 GMT+0900 (KST) }

Why?

When 10 minutes elapses and it refreshes the cache, the original correct Jan 04 is returned.

If I don't use async-cache and use fs.stat() every time I need, I correctly get Jan 04 stats. So, it's definitely somewhere inside async-cache that messes up the data.

Very weird. I'm using Node.js 0.8.12, and async-cache 0.1.0.

Edit: updated to Node.js 0.8.16. Same bug. I suppose the bug may be in lru-cache.

Please let me know if you have any idea why would this occur and if you have any suggestion how to fix this.

Thanks.

To reproduce:

node -e 'require("async-cache")({load:()=>{}}).get("__proto__",()=>{})'

fails with "TypeError: this._loading[key].push is not a function". (RunKit)

I think this is due to the get method directly using its key argument as a property name, which in this case messes up the prototype chain.

It would be nice if async-cache could be used together with recent version of lru-cache.

Currently, upgrading to lru-cache 7.4 results in 16 failed tests of async-cache's test suite.