[jira] [Comment Edited] (IGNITE-627) Inconsistent value in near cache

["Anton Vinogradov (Jira)" <ji...@apache.org>]

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

Anton Vinogradov edited comment on IGNITE-627 at 7/20/26 8:23 AM:
------------------------------------------------------------------

[Ignite PR Checker|https://ignite-pr-checker.is-a.dev/?pr=13316] verdict for PR 13316 · RunAll build [9215593|https://ci2.ignite.apache.org/build/9215593] · 147 suites ran, 0 reused

(?) *1 suite(s) ran fewer tests than on master* (tests that never ran can't fail):
- PDS 3: 3 tests vs 42 on master (*-93%*)

(/) No test blockers otherwise; 61 pre-existing/flaky filtered out.

♻️ Settled after 1 auto re-run wave(s): #1 — 1 broken suite(s).


was (Author: av):
[Ignite PR Checker|https://ignite-pr-checker.is-a.dev/?pr=13316] verdict for PR 13316 · RunAll build [9215593|https://ci2.ignite.apache.org/build/9215593] · 147 suites ran, 0 reused

(!) *1 broken suite(s)* (failed without a reliable run):
- PDS 3: execution timeout · non-zero exit code · Number of tests 3 is 93% less than 42 in build #40629 · 1 failed test detected

(?) *1 suite(s) ran fewer tests than on master* (tests that never ran can't fail):
- PDS 3: 3 tests vs 42 on master (*-93%*)

(/) No test blockers otherwise; 61 pre-existing/flaky filtered out.

⏳ _Auto re-run *#1* in progress — 1 broken suite(s) re-queued (attempt 1/2), *≈ settled by 11:23 MSK*. This comment updates when they settle._

> 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
>              Labels: MakeTeamcityGreenAgain, ise
>          Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> 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
(v8.20.10#820010)