[ 
https://issues.apache.org/jira/browse/GEODE-8278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alberto Gomez updated GEODE-8278:
---------------------------------
    Summary: Gateway sender queues using heap memory way above configured value 
after server restart  (was: Gateway sender queues using up a lot of heap space 
after server restart)

> Gateway sender queues using heap memory way above configured value after 
> server restart
> ---------------------------------------------------------------------------------------
>
>                 Key: GEODE-8278
>                 URL: https://issues.apache.org/jira/browse/GEODE-8278
>             Project: Geode
>          Issue Type: Bug
>          Components: eviction
>            Reporter: Alberto Gomez
>            Assignee: Alberto Gomez
>            Priority: Major
>
> In a Geode system with the following characteristics:
>  * WAN replication
>  * partition redundant regions
>  * overflow configured for the gateway senders queues by means of persistence 
> and maximum queue memory set.
>  * gateway receivers stopped in one site (B)
>  * Operations sent to the site that does not have the gateway receivers 
> stopped (A)
> When operations are sent to site A, the gateway sender queues start to grow 
> as expected and the heap memory consumed by the queues does not grow 
> indefinitely given that there is overflow to disk when the limit is reached.
> But, if a server is restarted, the restarted server will show a much higher 
> heap memory used than the memory used by this server before it was restarted 
> or by the other servers.
> This can even provoke that the server cannot be restarted if the heap memory 
> it requires is above the limit configured.
> According to the memory analyzer the entries taking up the memory are 
> subclasses of VMThinDiskLRURegionEntryHeap.
> The number of instances of this type are the same in the restarted server 
> than in the not restarted servers but on the restarted server they take much 
> more memory. The reason seems to be that they hold references to 
> previousEvictionNode and nextEvictionNode.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to