[ https://issues.apache.org/jira/browse/IGNITE-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16507078#comment-16507078 ]
Eduard Shangareev commented on IGNITE-627: ------------------------------------------ Hi, [~sboikov]. Do you plan to work on the ticket? > 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: Major > > 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 (v7.6.3#76005)