[
https://issues.apache.org/jira/browse/GEODE-8537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17220795#comment-17220795
]
Mario Salazar de Torres commented on GEODE-8537:
------------------------------------------------
Ok. So after looking into it. It seems that problem might that whenever destroy
occurs the entry is not removed from LRUList
It seemed odd at first to me that there was a mem peak in TcrMessage's
CacheableKeys in received notifications, like TcrMessage weren't being cleaned
up,
but that problem is actually due to the CacheableKey being a shared_ptr and
being passed onto the actual LRUList.
On the other side, the way currently LRU eviction is being handled seems not to
be pretty good in terms of design. Therefore I am considering a refactor.
> Memory increases whenever LRU eviction is enabled
> -------------------------------------------------
>
> Key: GEODE-8537
> URL: https://issues.apache.org/jira/browse/GEODE-8537
> Project: Geode
> Issue Type: Bug
> Components: native client
> Affects Versions: 1.13.0
> Reporter: Mario Salazar de Torres
> Assignee: Mario Salazar de Torres
> Priority: Major
> Attachments: massif-8419.png, massif.out.8419
>
>
> *HAVING* configured concurrency-checks-enabled=false in the client-cache.xml
> for a region
> *HAVING* configured heap-lru-limit=10 in the client-cache.xml for the region
> region
> *HAVING* configured heap-lru-delta=10 in the client-cache.xml for the region
> region
> *HAVING* configured subscription-notification for the pool on which the
> region is defined
> *HAVING* regsitered interest on all the keys of this region, values included
> *AFTER* receiving lots of LOCA_CREATE and LOCAL_DESTROY notifications
> *THEN* memory increases continously over time, even going over the LRU limit.
> Find massif tool report as massif.out.8419 showing the memory increase.
> Also this is a capture of massif-visualizer for the report:
> !massif-8419.png!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
