[
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)
