Dmitriy Pavlov commented on IGNITE-7845:

[~akalashnikov], please set patch available if fix is ready

> Data race on atomicLong close
> -----------------------------
>                 Key: IGNITE-7845
>                 URL: https://issues.apache.org/jira/browse/IGNITE-7845
>             Project: Ignite
>          Issue Type: Bug
>            Reporter: Anton Kalashnikov
>            Assignee: Anton Kalashnikov
>            Priority: Major
>              Labels: MakeTeamcityGreenAgain
>             Fix For: 2.5
> Found by IgniteClientDataStructuresTest.testAtomicLong.
> *Given:*
> IgniteAtomicLong was created e.g. atomicLong = ignite.atomicLong("long1", 1L, 
> true)
> *When:*
> IgniteAtomicLong was closed e.g. atomicLong.close()
> *Then:*
> If you try to get this value again sometimes you will get null 
> IgniteAtomicLong value and sometimes you will get not null IgniteAtomicLong 
> value e.g. ignite.atomicLong("long1", 1L, false) sometimes null, sometimes 
> not null
> But if we will get not null value IgniteAtomicLong and we will call method 
> "get" on it, we will have one of two exception 
> IllegalStateException("Sequence was removed from cache: " + name) if it 
> already marked as deleted, and IgniteException("Failed to find atomic long: " 
> + name) if it sill no marked as deleted but already deleted from cache.
> *Expected:*
> IgniteAtomicLong value always should be null(or not?)
> *Why it's happend:*
> When we close IgniteAtomicLong we removing value from cache in transaction 
> but removing from internal storage(dsMap) happen asynchroniously in 
> DataStructuresEntryListener for all nodes include local node. And when we try 
> get value after close we still sometimes able to get IgniteAtomicLong from 
> internal local storage.
> *Solution(In my opinion):*
> I guess in common case we don't  need call Ignite#atomicLong  every time when 
> we need value, but we should use IgniteAtomicLong object received after first 
> call. And if it is true, we can remove receiving IgniteAtomicLong from local 
> storage(dsMap) - this changes will fix problem

This message was sent by Atlassian JIRA

Reply via email to