membphis commented on PR #14061: URL: https://github.com/apache/apisix/pull/14061#issuecomment-6339539539
@nic-6443 Could you please double-check these two potential P1 issues? They came out of a follow-up discussion of the required cache behavior. The single-resource URL-switch case appears improved. The remaining requirement is one retained compiled result per URL per worker, with identical fetch settings. Temporary overlap during refresh is acceptable, but the caches must eventually converge on the current result and release old generations, including when some resources become idle. ### [P1] Old compiled generations of the same URL can remain indefinitely Each resource slot strongly references an entry, while refreshing replaces the URL index and only the resource slot being refreshed. Idle resources can therefore retain old compiled generations after their TTL has elapsed. Reproduction: - Use one URL and 101 resource keys: one resource keeps refreshing, while each of the other 100 accesses one generation and then stays idle. - Produce 100 compiled generations in total, including the initial load, with a 10-second TTL. - Advance time far beyond the TTL, run background refresh checks, and perform full GC. - The baseline retains one result object; the PR implementation retains 100. This also matches [the existing upstream discussion](https://github.com/apache/apisix/pull/14061#discussion_r4346883710). The relevant paths are [entry replacement](https://github.com/apache/apisix/blob/87a586549add448cf3b322971ef1b3c077f5107d/apisix/plugins/oas-validator.lua#L215-L218) and [resource-local retention](https://github.com/apache/apisix/blob/87a586549add448cf3b322971ef1b3c077f5107d/apisix/plugins/oas-validator.lua#L285-L293). Could you confirm how idle-resource references are eventually invalidated? A possible direction is for resources to reference the same replaceable URL state, so a successful refresh switches the current result for all resources and releases obsolete references. ### [P1] Resource-count eviction can repeatedly refetch still-fresh specifications The 512-entry limit now counts resources. Evicting the last resource slot for a URL can make its compiled result collectible even though the URL result is still within TTL. Reproduction: - In one worker, sequentially cycle through 1,000 resource keys. - The first 400 each use a distinct URL; the remaining 600 share one additional URL: 401 URLs total. - Keep time within TTL and force GC after requests to collect evicted results. - After warm-up, the baseline makes zero fetch-function calls on the second pass. The PR makes 400 fetch/compile calls and recreates 1,000 resource slots. All 401 URLs fit in the previous 512-entry URL cache. The concern is the additional large-spec download and compilation work caused by resource eviction, rather than the bounded metadata table itself. Could you confirm this behavior and whether URL-result retention can be decoupled from the resource-table limit while still reclaiming unused old specifications? These are targeted LuaJIT lifecycle probes using the PR's plugin/core LRU code and the upstream resty.lrucache v0.13 implementation. HTTP, compiler results, time, and locking were stubbed to isolate ownership and eviction; these are not full-gateway tests or RSS/throughput measurements. Please verify both cases against the real gateway and confirm or correct the findings before changing the implementation. -- 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]
