You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@geode.apache.org by "Darrel Schneider (JIRA)" <ji...@apache.org> on 2016/04/22 20:13:12 UTC
[jira] [Commented] (GEODE-1277) Partitioned region replace and
remove could be optimized for off-heap
[ https://issues.apache.org/jira/browse/GEODE-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15254355#comment-15254355 ]
Darrel Schneider commented on GEODE-1277:
-----------------------------------------
Another message that could have this same optimization is:
com.gemstone.gemfire.internal.cache.tier.sockets.command.Destroy65.cmdExecute(Message, ServerConnection, long)
See the "expectedOldValue". This a client/server message (the previous ones a p2p).
> Partitioned region replace and remove could be optimized for off-heap
> ---------------------------------------------------------------------
>
> Key: GEODE-1277
> URL: https://issues.apache.org/jira/browse/GEODE-1277
> Project: Geode
> Issue Type: Bug
> Components: offheap
> Reporter: Darrel Schneider
>
> The following message classes exist for a partitioned region replace and remove:
> com.gemstone.gemfire.internal.cache.partitioned.DestroyMessage
> com.gemstone.gemfire.internal.cache.partitioned.PutMessage
> both of these messages distributed the "expected value" from a ConcurrentMap replace or remove. The way the expected value is distributed always requires it to be deserialized when it the message is processed.
> But when this message is processed on an off-heap region we only need to compare the serialized bytes stored off-heap to the serialized expected value. So not only did we not need to deserialize the expected value when the message is deserialized (in the message's fromData method), when end up needing to reserialize it to figure out if the current value is equal to it.
> This would be a pretty simple change but would require a change in how the expectedValue field is serialized and deserialized in toData/fromData. We want it to deserialize as a VMCachedDeserializable that contains the serialized bytes of the expected value.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)