Aias00 opened a new issue, #7713: URL: https://github.com/apache/shenyu/issues/7713
### Current behavior Each `MemoryCache.cacheData()` call allocates a separate Guava cache for a single response key and stores that cache in an outer `ConcurrentHashMap`. The TTL applies only to the inner byte entry. It does not evict the outer key or the inner cache object from `mainCache`. Outer entries are removed only if a later `isExist(key)`/`getData(key)` call revisits that exact expired key, or when the entire backend is closed. Normal traffic that continuously creates new response keys without revisiting them therefore grows the retained map with historical keys even after their configured TTLs elapse. ### Location [MemoryCache.java:36–55,65–70](https://github.com/apache/shenyu/blob/66d7d954ca37d651a5ad916f988a8081157a7ab4/shenyu-plugin/shenyu-plugin-cache/shenyu-plugin-cache-memory/src/main/java/org/apache/shenyu/plugin/cache/memory/MemoryCache.java#L36). ### Reproduction / validation A standalone Java probe compiled the current MemoryCache source, wrote 100 distinct keys with a one-second TTL, waited 1.1 seconds, and inspected the index. It also explicitly called Guava cleanup on each inner cache to separate the outer-index problem from Guava's lazy payload cleanup: ```text EXPIRED_MEMORY_OUTER=100 INNER_LIVE=0 ``` The outer map still retained all 100 keys/cache objects even after no live inner values remained. An independent reviewer confirmed that no production expiry callback/maintenance path removes these outer entries. This is a small controlled retention reproduction, not an OOM or throughput benchmark. ### Impact Heap retention grows with the number of distinct cached response keys over process lifetime rather than the live TTL window. At minimum keys and one Guava cache's bookkeeping remain reachable per historical key; this report does not depend on claiming expired payload bytes are always retained. ### Suggested fix Make response-entry expiry and index eviction share ownership, while preserving the per-entry timeout API. Avoid allocating a full standalone Guava cache per response key. Introduce a bounded retention policy and/or maintenance that evicts expired index entries independently of revisiting each key. ### Related existing work Live MemoryCache/mainCache searches returned no exact issue. #1477 concerns weighting of RPC reference caches; #4243 concerns hot-loaded JAR retention; #3063 concerns HTTP client runOn usage. #7156/#7163 concern Redis client lifecycle. Broad historical memory-usage reports do not identify this per-response-key expired index retention. ### Reviewed revision Apache ShenYu 2.7.2-SNAPSHOT, `master@66d7d954ca37d651a5ad916f988a8081157a7ab4`. Severity Medium / P2; confidence high. Unit-test and CI issue categories excluded. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
