[infinispan-issues] [JBoss JIRA] (ISPN-4979) CacheStatusResponse map uses too much memory

William Burns (JIRA) issues at jboss.org
Mon Nov 17 12:52:39 EST 2014


    [ https://issues.jboss.org/browse/ISPN-4979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020539#comment-13020539 ] 

William Burns commented on ISPN-4979:
-------------------------------------

Looking at the response closer, it as suspected.  Each address is a unique object in memory.  This even includes addresses that were deserialized as children of the same object that references both (example a consistent hash can have 1 or more member sets where none of the Address objects are reused).  Unfortunately reusing the objects in the same river marshaller invocation wouldn't benefit us since each deserialization happens N times for the response, one from each node.

It seems we can work around this by having custom externalizer implementation that does this caching itself, but I want to double check some things first.

> CacheStatusResponse map uses too much memory
> --------------------------------------------
>
>                 Key: ISPN-4979
>                 URL: https://issues.jboss.org/browse/ISPN-4979
>             Project: Infinispan
>          Issue Type: Bug
>          Components: Core, State Transfer
>    Affects Versions: 7.0.0.Final
>            Reporter: Dan Berindei
>            Assignee: William Burns
>            Priority: Critical
>             Fix For: 7.1.0.Final
>
>
> When the cluster is large and there are a log of caches, the {{CacheStatusResponse}} map on the new coordinator can get quite large. One of the problems that seems to be that the addresses in {{DefaultConsistentHash}} are duplicated on serialization, so the deserialized version occupies more memory.
> We need to investigate why the objects are not "shared" by the River marshaller, and maybe work around the problem by de-duplicating the addresses in the externalizer.



--
This message was sent by Atlassian JIRA
(v6.3.8#6338)


More information about the infinispan-issues mailing list