[
https://issues.apache.org/jira/browse/HTTPCLIENT-2284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17745212#comment-17745212
]
Oleg Kalnichevski commented on HTTPCLIENT-2284:
-----------------------------------------------
[~lacompas] We are not going to change the way HC 4.5 works. The HTTP caching
layer is undergoing a major upgrade in the 5.3.x branch. Please re-test your
code with the latest 5.3.x snapshot:
[https://github.com/apache/httpcomponents-client/tree/5.3.x]
I will have to close the ticket as WONTFIX otherwise.
Oleg
> 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: Major
>
> 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: [email protected]
For additional commands, e-mail: [email protected]
