[jira] [Commented] (GEODE-7670) Partitioned Region clear operations can occur during concurrent data operations

["ASF GitHub Bot (Jira)" <ji...@apache.org>]

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

ASF GitHub Bot commented on GEODE-7670:
---------------------------------------

jujoramos commented on pull request #4848:
URL: https://github.com/apache/geode/pull/4848#issuecomment-638087431


   @agingade 
   According to what we discussed offline about the `clear` operation:
   > - The clear may be successful or partial.
   > - In case of partial, it will throw `PartitionedRegionPartialClearException`.
   > - In both cases, the secondary bucket data should be same as primary (even with member departing).
   > - The `RegionVersionVector` between primary and secondary should be same, no matter what.
   
   Having that in mind, I've re-based the `PR` against the latest changes from the `feature/GEODE-7665` branch. There are still some test failures, below are the details:
   
   - Test **clearWithConcurrentPutsShouldWorkCorrectly** always fails for `PARTITION_REDUNDANT` regions, doesn't matter whether the clear coordinator is the actual data host or the accessor node. After the clear finishes, the `RegionVersionVector` is not the same on the primary and secondary copies for a particular bucket.
   - Test **clearShouldFailWhenCoordinatorMemberIsBounced** always fails for `PARTITION_REDUNDANT` regions. After the clear finishes, the `RegionVersionVector` is not the same on the primary and secondary copies for a particular bucket.
   - Test **clearWithConcurrentPutAllShouldWorkCorrectly** always fails for `PARTITION_REDUNDANT` regions, doesn't matter whether the clear coordinator is the actual data host or the accessor node. After the clear finishes, the `RegionVersionVector` is not the same on the primary and secondary copies for a particular bucket.
   - Test **clearWithConcurrentPutsAndGetsShouldWorkCorrectly** always fails for `PARTITION_REDUNDANT` regions, doesn't matter whether the clear coordinator is the actual data host or the accessor node. After the clear finishes, the `RegionVersionVector` is not the same on the primary and secondary copies for a particular bucket.
   - Test **clearWithConcurrentPutsShouldWorkCorrectlyWhenNonCoordinatorMembersAreBounced** randomly fails (for `PARTITION_REDUNDANT` regions) with `PartitionedRegionPartialClearException` or inconsistent `RegionVersionVector` across buckets copies, I believe I'm hitting the same scenario as the one @DonalEvans described [here](https://github.com/apache/geode/pull/5095/files#r432000642).
   
   Thoughts?.
   


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


> Partitioned Region clear operations can occur during concurrent data operations
> -------------------------------------------------------------------------------
>
>                 Key: GEODE-7670
>                 URL: https://issues.apache.org/jira/browse/GEODE-7670
>             Project: Geode
>          Issue Type: Sub-task
>          Components: regions
>            Reporter: Nabarun Nag
>            Assignee: Juan Ramos
>            Priority: Major
>              Labels: GeodeCommons
>          Time Spent: 5.5h
>  Remaining Estimate: 0h
>
> Clear operations are successful when concurrent read/write operations occur. Ensure there are test coverage for this use case and modify the code needed to enable this.
> Acceptance :
>  * Passing DUnit tests where clear operations are successful on partitioned region with 
>  * concurrent puts (writes) and clear op
>  * concurrent gets (reads) and clear op
>  * Test coverage to when a member departs in this scenario
>  * Test coverage to when a member restarts in this scenario
>  * Unit tests with complete code coverage for the newly written code.



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