[ https://issues.apache.org/jira/browse/IGNITE-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14907971#comment-14907971 ]
Semen Boikov commented on IGNITE-627: ------------------------------------- As part of the fix for this issue it is necessary to add data consistency test using near cache with eviction policy. > Inconsistent value in near cache > -------------------------------- > > Key: IGNITE-627 > URL: https://issues.apache.org/jira/browse/IGNITE-627 > Project: Ignite > Issue Type: Sub-task > Components: cache > Reporter: Semen Boikov > Assignee: Semen Boikov > Priority: Critical > > This scenario is possible in atomic cache with near cache enabled: > - key is updated concurrently from near and primary node > - primary node first executes update request from near node, registers it as > reader and sends GridNearAtomicUpdateResponse to near node > - then primary node executes second update, sees that there is a reader and > sends GridDhtAtomicUpdateRequest to near node > - GridDhtAtomicUpdateRequest is handled first on near node (see > GridNearAtomicCache.processDhtAtomicUpdateRequest), it tries to peek entry, > it is not created yet and it is considered as evicted, updated is skipped and > reader will be removed on primary node > - then near node handles GridNearAtomicUpdateResponse and creates entry with > incorrect value > Tests > GridCacheValueConsistencyAtomicPrimaryWriteOrderNearEnabledSelfTest.testPutRemoveConsistencyMultithreaded > and testPutConsistencyMultithreaded fail from time to time because of this > issue. > Most probably there is similar issue in transactional cache since > GridCacheValueConsistencyTransactionalNearEnabledSelfTest also fails from > time to time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)