Inconsistent usage of set method in custom cache handler for shared cache management on Amazon EFS #77741
Unanswered
LorenzoGalassi
asked this question in
Help
Replies: 1 comment 1 reply
-
Just to see if I am understanding, from your side, if the getting data, gives And it is not possible for the stored value, to ever be null? Can you inspect the ECS fs, to see what's getting stored? Or if you have the permissions needed? I feel like I've seen a somewhat similar issue somewhere. Also, local production builds work fine too right? |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Summary
Hello everyone,
I am trying to make a custom cache handler because I have an application on ECS and I would like to use a shared cache by having it reside on a shared file system (EFS).
I've currently gotten this far with the code:
The problem I am experiencing is that there are “SET” logs after cache hits without a revalidation between the two events. The logic I expect to happen internally in the framework is:
3.1 If GET = null => I fetch and use a SET on the cache
3.2 If GET != null => I do not perform the fetch
The only case where GET = null is if the call was never cached or if a revalidation was invoked, both of which are not happening in my local tests after a cache hit that I detecto from logs.
I ask: am I missing something?
N.B. obviously there are no
revalidate = 0
or similar in the code, if I remove the custom cache handler the caching works correctlyAdditional information
No response
Example
No response
Beta Was this translation helpful? Give feedback.
All reactions