[
https://issues.apache.org/jira/browse/GEODE-6695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16824410#comment-16824410
]
Darrel Schneider commented on GEODE-6695:
-----------------------------------------
Another problem with the canonicalization of ClientProxyMembershipID instances
is that the maps in the CacheClientNotifier used to do the canonicalization
will be empty unless you have a subscription (i.e. server-to-client)
connection. To correctly implement this improvement I think the canonical data
should be tracked as the cache server detects new clients and client
departures. Some code that currently does this is:
ServerConnection.getCleanupProxyIdTable(). The other challenge is we currently
have 20 different callers of this static method:
ClientProxyMembershipID.readCanonicalized(DataInput). Since it is static it
needs to have a way to find the canonical data and it currently does this by
going to the CacheClientNotifier singleton. This could continue for now but
eventually we want to get rid of this pattern. Deserialization code that calls
static methods is hard to refactor. A better pattern is for the message
deserialization to just read the data off the wire and save other work for
later when we start processing the message. Another possibility would be to
have some type of serialization context object that is passed around as we do
deserializations (we could hide it in the object that implements DataInput
since that is passed to all the fromData calls).
> ClientProxyMembershipID.canonicalReference allocates lots of objects
> --------------------------------------------------------------------
>
> Key: GEODE-6695
> URL: https://issues.apache.org/jira/browse/GEODE-6695
> Project: Geode
> Issue Type: Improvement
> Components: serialization
> Reporter: Darrel Schneider
> Assignee: Darrel Schneider
> Priority: Major
>
> ClientProxyMembershipID.canonicalReference ends up allocating a large number
> of objects that get garbage collected. The cause of this is that when it goes
> to do a lookup on the ConcurrentHashMap to see if a canonical id exists, it
> calls ClientProxyMembershipID.hashCode which in turn calls isDurable(). This
> method calls getDistributedMember which does a deserialization of the
> identity byte array which does lots of object allocations.
> I think we can instead check for a ClientProxyMembershipID whose uniqueId and
> identity are equal. If we find one then we can use it as the canonical id.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
