[
https://issues.apache.org/jira/browse/HTTPCLIENT-2284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17750474#comment-17750474
]
Pascal Lacombe commented on HTTPCLIENT-2284:
--------------------------------------------
[~olegk] I believe this problem applies to all cache storage implementation, as
they all store a root entry with a variantMap. The issue stems from have the
storage evict variant entries without notifying that the root's variantMap
needs to be cleaned.
We worked around the issues internally by leveraging the variantKey's syntax
(i.e. "\{variant}url") to find the root entry and clean it's variantMap using
reflection. However this isn't a great solution, and I'm not sure it can apply
for all storage implementations.
Perhaps a more generic solution would be for HttpCacheEntry to retain both its
rootKey and variantKey. This way you have the pieces required for cleanup the
root on eviction. Then passing to CacheMap an operation similar to
HttpCacheCASOperation to implement what needs to happen to the root entry.
> BasicHttpCacheStorage leaking variant keys in root response's variantMap
> ------------------------------------------------------------------------
>
> Key: HTTPCLIENT-2284
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2284
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpCache
> Affects Versions: 4.5.13
> Reporter: Pascal Lacombe
> Priority: Minor
> Fix For: 5.3-alpha1
>
> Attachments: 0001-Add-disabled-test-for-HTTPCLIENT-2284.patch
>
>
> BasicHttpCacheStorage has a memory leak in the root response's variantMap.
> When a variant cached entry is evicted due to CacheMap being too large, the
> root cache entry does not remove the variant key in its variantMap. This is a
> memory leak that can grow the variantMap indefinitely, or until the root
> entry get's evicted itself.
> Simplified testcase:
> # A request is being sent from a client that contains a header
> "x-my-variant" with a hash of the current timestamp.
> # The server responds 200, with a cacheable response. The response Vary's on
> "x-my-variant"
> # These requests repeat, causing:
> ## The "root" CacheEntry to be kept in CacheMap
> ## The oldest variant CacheEntry to be evicted due to the CacheMap size limit
> ## However the "root" CacheEntry never removes the evicted variant keys from
> the variantMap
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
