sarkistlt / feathers-redis-cache Goto Github PK

I have a query that is like this.

{
  $and: [
    { tags: { $in: ['5d27187cdcfb01b6e35e04fe', '5d2718dddcfb01022b5e0505'] } },
    { product: '5debaed9ee579bdd6036f353' }
  ];
}

however when that is cached it's converted to $and=[object Object],[object Object] which means the same result is returned regardless of the $and query.

I've noticed that if I remove arrayFormat: 'comma' from the stringify options the result looks much better so was wondering if there is a particular reason for this being set as feathers-rest doesn't use it. https://github.com/feathersjs-ecosystem/feathers-rest/blob/master/src/client/base.js

$and[0][tags][$in][0]=5d27187cdcfb01b6e35e04fe&$and[0][tags][$in][1]=5d2718dddcfb01022b5e0505&$and[1][product]=5debaed9ee579bdd6036f353

Redis-x64-3.2.100 - Windows

"feathers-redis-cache": "^1.2.1",

Purge that is error.

{ message: "ERR unknown command 'unlink'", status: 500 }

We're using groups to store our keys and then use these groups to delete keys in batches.

It seems that due to this line of the purgeGroup function it might be returning a false negative result, scan returns an empty list for some cases that there are keys present for a given group.

Here is an example of this happening, when we used RedisInsight:

• command used by feathers-redis-cache
  scan 0 "MATCH" "abc_123*" "COUNT" "1000"

• Output
  1) "845" 2) (empty list or set)

• command used for testing purposes
  scan 0 "MATCH" "abc_123*" "COUNT" "10000"

• Output
  1) "0" 2) 1) "abc_123-AAAA" 2) "abc_123-BBBBB" 3) "abc_123-CCCCC"

Hello,

I am trying to figure out how to store a User in Redis to reference from other feathers servers in network. Can't seem to get this package to work.

Fresh install of Feathers server and feathers-redis-cache results in the following:

Error

My app.js

My users hooks

My package.json dependencies:

Just wondering if you have any suggestions for the best way to use with fastjoin. I'm assuming it should implemented after the fastjoin but I don't want fastjoin to then run on a cached response as that would defeat the purpose.

Would this be the correct way to do it?

    get: [
      isNot(hook => hook.params.$skipCacheHook, fastJoin(viewResolver)),
      redisCache.hooks.after({ expiration: 3600 * 24 * 7 })
    ],

Hi! First of all, nice project you got here, thanks for sharing it :)

We tried using this hook in a project we're about to finish, but when we did some load testing, we found some problems that cause slowdown and high memory usage.

After noticing these problems and finding the issue, I saw in your TODO list this: "option in after hook to set limit of keys per group". I believe that is a must for a production environment.

But anyways, that is not the problem per se (although it's closely related).

After many load tests, I noticed that the group list in redis was huge. When I analyzed the code, I noticed two things that contribute to this problem:

• The group list itself is not purged after deleting all the entries that it refers too, so it grows indefinitely
• The group list is not checked when pushing a new entry, so it allows for duplicate entries. At first it may not seem a problem, but it makes the first problem more impactful, because after a purge, everything in the list may be duplicated. If the group list is in fact correctly purged all the time, this should not be a problem at all, because theoretically you wouldn't get to an after hook if that path is in fact cached. But this could in fact happen a lot in a distributed environment, where you have multiple instances of your API purging and caching simultaneously.

I suggest that instead of creating the group list, maybe put the group as a cache key prefix, and when purging, just use the "keys" function to find all keys related to that group. Some care would have to be taken to avoid problems with groups named with a same prefix and things like that. I haven't exactly put a lot of thought into this, but these were the first things that came to my mind.

I may find some time in the near future to make a pull request addressing this issue, but I believe caching won't be a priority for us at the moment, so it may take some time.