[
https://issues.apache.org/jira/browse/HTTPCLIENT-2284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757429#comment-17757429
]
Oleg Kalnichevski commented on HTTPCLIENT-2284:
-----------------------------------------------
> Perhaps a more generic solution would be for HttpCacheEntry to retain both
> its rootKey and variantKey.
[~lacompas] I think that storing keys in the cache entry is conceptually wrong.
The cache keys are implementation specific. The actual key and the one stored
inside the entry can get out of sync. The same entry can in fact be stored
multiple times with different keys. What I have done in interim is normalizing
the request URI stored in the cache entry using the same algorithm as the one
used to generate the root key, so the request URI of the entry should actually
be identical to its root key. However I am reluctant to make this a part of the
official API contract. In the future this may no longer be the case.
For the time being your only option is building your onw custom
{{HttpCacheStorage}} that can do extra cleanups upon eviction of cache entries.
> 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-alpha2
>
> Attachments: 0001-Add-disabled-test-for-HTTPCLIENT-2284.patch
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> 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
