[ 
https://issues.apache.org/jira/browse/GEODE-6287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16745352#comment-16745352
 ] 

Barry Oglesby commented on GEODE-6287:
--------------------------------------

Startup:
{noformat}
 num #instances #bytes class name
----------------------------------------------
 1: 28887 2606096 [C
 2: 7205 810664 java.lang.Class
 3: 28820 691680 java.lang.String
 4: 2004 494408 [B
 5: 5153 453464 java.lang.reflect.Method
 6: 5538 425016 [Ljava.lang.Object;
 7: 657 389224 [J
 8: 11600 371200 java.util.concurrent.ConcurrentHashMap$Node
 9: 8124 324960 java.util.LinkedHashMap$Entry
 10: 3047 277584 [Ljava.util.HashMap$Node;
 11: 8536 273152 java.util.HashMap$Node
 12: 2533 202640 java.lang.reflect.Constructor
 13: 4764 198616 [I
 14: 10575 169200 java.lang.Object
 15: 2749 153944 java.util.LinkedHashMap
Total 181128 9653224
{noformat}
With 15000 client connects/registerInterests/disconnects:
{noformat}
 num #instances #bytes class name
----------------------------------------------
 1: 104958 9068952 [C
 2: 104852 2516448 java.lang.String
 3: 16604 2160248 [B
 4: 41802 1337664 java.util.concurrent.ConcurrentHashMap$Node
 5: 15005 1080360 org.apache.geode.distributed.internal.membership.gms.GMSMember
 6: 7473 840680 java.lang.Class
 7: 15005 720240 
org.apache.geode.distributed.internal.membership.InternalDistributedMember
 8: 15031 480992 java.net.InetAddress$InetAddressHolder
 9: 14996 479872 org.apache.geode.distributed.DurableClientAttributes
 10: 14995 479840 
org.apache.geode.internal.cache.tier.sockets.ClientProxyMembershipID
 11: 5949 445136 [Ljava.lang.Object;
 12: 25820 413120 java.lang.Object
 13: 756 407840 [J
 14: 15225 365400 java.lang.Long
 15: 15026 360624 java.net.Inet4Address
Total 501811 24712960
{noformat}

> When a client connects, registers interest and disconnects normally, its 
> ClientProxyMembershipID is not cleaned up and a memory leak occurs
> -------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: GEODE-6287
>                 URL: https://issues.apache.org/jira/browse/GEODE-6287
>             Project: Geode
>          Issue Type: Bug
>          Components: client queues, client/server
>            Reporter: Barry Oglesby
>            Assignee: Barry Oglesby
>            Priority: Major
>
> When a client connects to a distributed system and registers interest, the 
> Region's FilterProfile's clientMap (an IDMap) registers the 
> ClientProxyMembershipID in both the realIDs and wireIDs like:
> {noformat}
> realIDs={identity(192.168.2.12(client-register:52879:loner):63013:2327c553:client-register,connection=2=1};
> wireIDs={1=identity(192.168.2.12(client-register:52879:loner):63013:2327c553:client-register,connection=2}
> {noformat}
> When the client leaves normally, the UnregisterInterest command is invoked 
> which removes the interest and the region. Part of that behavior is to remove 
> the regionName from the set of regions.
> {noformat}
> this.regions.remove(regionName)
> {noformat}
> Then ClientInterestList.clearClientInterestList is then invoked which is 
> supposed to clear the FilterProfile for each region, but the regions are 
> already cleared by the UnregisterInterest command, so this method doesn't do 
> anything.
> Then, LocalRegion.cleanupForClient is invoked which invokes 
> FilterProfile.cleanupForClient. This method currently only closes CQs (which 
> also cleans up the cqMap which is also an IDMap like the clientMap).
> At the end of this, the clientMap's realIDs and wireIDs still contain the 
> ClientProxyMembershipID.
> The cleanupForClient method could be changed to also clean up the clientMap.
> Note: If the client is killed abnormally, the UnregisterInterest command is 
> not invoked, so the interest and the region is not cleaned up normally. When 
> ClientInterestList.clearClientInterestList is called, the set of regions 
> still contains the region, and the IDMap is cleaned up properly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to