ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dmitriy Govorukhin (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (IGNITE-627) Inconsistent value in near cache
Date Wed, 16 Aug 2017 14:57:00 GMT

     [ https://issues.apache.org/jira/browse/IGNITE-627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Dmitriy Govorukhin updated IGNITE-627:
    Priority: Major  (was: Critical)

> 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
>             Fix For: 2.2
> 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
> 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

View raw message