[
https://issues.apache.org/jira/browse/HTTPCLIENT-2284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17746497#comment-17746497
]
Pascal Lacombe edited comment on HTTPCLIENT-2284 at 7/24/23 3:18 PM:
---------------------------------------------------------------------
[~olegk] in our product we vary the responses per user session in order to
preserve cache privacy. Therefor the number of variant records depends on the
number of user sessions, and how long the root entry is preserved in cache.
The impact seems to be mostly performance degradation, as the root entry's
variantMap get's reconstructed twice per update (due to variantMap being
unmodifiable) and this takes more time as the variantMap grows.
was (Author: JIRAUSER301432):
[~olegk] in our product we vary the responses per user session in order to
preserve cache privacy. Therefor the number of variant records depends on how
the number of user sessions, and how long the root entry is preserved in cache.
The impact seems to be mostly performance degradation, as the root entry's
variantMap get's reconstructed twice per update (due to variantMap being
unmodifiable) and this takes more time as the variantMap grows.
> 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
>
>
> 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
