[jboss-jira] [JBoss JIRA] Resolved: (JGRP-1016) memory leak in GMS protocol

[Bela Ban (JIRA)]

     [ https://jira.jboss.org/jira/browse/JGRP-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1016.
----------------------------

    Fix Version/s:     (was: 2.6.12)
       Resolution: Done


A similar issue was observed for ack_collector. In both cases, received_acks was removed from AckCollector and merge_ack_colletctor was reset when a coord ceased to be coord

> memory leak in GMS protocol
> ---------------------------
>
>                 Key: JGRP-1016
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1016
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.7
>            Reporter: Miro Selent
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> Found in org.jgroups.protocols.pbcast.GMS in a scenario where members were killed and restarted very frequently and one member is persistently running. The memory consumption icreased very quickly until OutOfMemory.
> Our analysis with JProfiler leads to the following assumption:
> The number of org.jgroups.stack.IpAddress held by merge_ack_collector icreases every time a member was (re)started. 
> These instances were never removed because no MERGE events occured. This is completely clear since there was only one coordinator (the long running member). 
> If GMS receives no MERGE event it never cleans up the stored IpAddress instances in the merge_ack_collector.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira