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

Darrel Schneider commented on GEODE-9670:
-----------------------------------------

The test was expecting something that geode does not do.
It was expecting a jedis.set done twice to cause the value stored in memory to 
be deserialized on both the primary and the secondary. It thought this would 
happen because it expected (according to comments in the test) for the 2nd set 
to use delta propagation. But our implementation of "set" on RedisString never 
uses delta. And because of the way the geode internals handle values, the 
RedisString created for a "set" will always be deserialized on the primary and 
will always be serialized on the secondary. I will file another ticket 
suggesting that we reimplement RedisString ops to consistently use a Delta when 
an update is done. But for this ticket I will just fix the test's expectations.

> PartitionedRegionStatsUpdateTest.should_showMembersAgreeUponUsedStringMemory_afterDeltaPropagation
>  Fails
> --------------------------------------------------------------------------------------------------------
>
>                 Key: GEODE-9670
>                 URL: https://issues.apache.org/jira/browse/GEODE-9670
>             Project: Geode
>          Issue Type: Test
>          Components: redis
>            Reporter: Wayne
>            Assignee: Darrel Schneider
>            Priority: Major
>              Labels: pull-request-available
>
> The 
> PartitionedRegionStatsUpdateTest.should_showMembersAgreeUponUsedStringMemory_afterDeltaPropagation
>  test is currently disabled using the @Ignore annotation.  Before we can 
> enable the tests, we must find a way to force deserialization on both members.
> +Acceptance Criteria+
> The 
> PartitionedRegionStatsUpdateTest.should_showMembersAgreeUponUsedStringMemory_afterDeltaPropagation
>  test no longer fails and the @Ignore annotation has been removed.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to