Open toddmgreer opened 4 years ago
Is there any guidance as to what needs to be done to resolve this?
any update here?
Resolving this will at least require implementing a cap on estimated or actual memory usage, including evicting entries and rejecting excessively large insertions. Most likely, whoever decides to be the first to use SimpleHttpCache in production will find and fix whatever issues we haven't thought of (as with all software, it's buggy until proven otherwise). If you'd like to pursue this, I'll happily support you.
Hi @toddmgreer , I am interested in improving the SimpleHttpCache. What do you think of leveraging the existing lru_cache lib from jwt_verify_lib/simple_lru_cache to make cache eviction work as a starting point?Or if you want to keep SimpleHttpCache simple, maybe write a new production-ready http cache implentation?
Hi @bryanwux, I'm excited that you want to improve SimpleHttpCache. My hope is that it can become production-ready and stay simple enough to serve as a reference. I think jwt_verify_lib/simple_lru_cache isn't thread-safe, so you'll need to deal with that.
@capoferro, you were looking at addressing this--did you put anything into motion?
@toddmgreer Some work was done here: https://github.com/capoferro/envoy/tree/lru_cache. Cooper Bethea volunteered to put some work into that, but it has gone stale.
Can see the diff here: https://github.com/envoyproxy/envoy/compare/main...capoferro:envoy:lru_cache
Seems like it's workable right now. Why it has gone stale? @capoferro
I haven't looked at the branch in much detail since Cooper took it over. If it works for what you need, by all means pull the branch and merge up to current main. Would love to see this get into main in some form.
SimpleHttpCache is a minimal proof-of-concept HttpCache implementation that pays no attention to memory usage, and doesn't ever delete entries. It should be built into a production-ready in-process in-memory cache.