You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Semen Boikov (JIRA)" <ji...@apache.org> on 2017/09/25 12:41:00 UTC
[jira] [Updated] (IGNITE-627) Inconsistent value in near cache
[ https://issues.apache.org/jira/browse/IGNITE-627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Semen Boikov updated IGNITE-627:
--------------------------------
Fix Version/s: (was: 2.3)
> 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
>
> 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.4.14#64029)