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

Artem Shutak commented on IGNITE-2645:
--------------------------------------

I discussed the Alexey's comment with him today and now I see the problem. 
'putIfAbsent' will has the same issue.

The following steps can be used to verify that the issue exists:
1. Put key-value pair at cache.
2. Clear the value for the key from primary node (backup node should still has 
the value).
3. Execute invoke operation, which doesn't change a value, just return 
something.
4. Check that entry version equals no primary and backup. Expected that now it 
fails here.

At point 3, Ignite will read value from store (on innerGet), new entry version 
will be genarated, but as long as entry processor does not change the value, 
value will not be updated on backup node.

I think, we should fix the issue in bounds of new jira.

Thoughts?

> Assertion error in ATOMIC cachce for invokeAll and cache store
> --------------------------------------------------------------
>
>                 Key: IGNITE-2645
>                 URL: https://issues.apache.org/jira/browse/IGNITE-2645
>             Project: Ignite
>          Issue Type: Bug
>          Components: cache
>    Affects Versions: ignite-1.4
>            Reporter: Alexey Goncharuk
>            Assignee: Artem Shutak
>              Labels: community
>             Fix For: 1.6
>
>         Attachments: EntryProcessorFails.java
>
>
> Assertion happens under the following conditions:
>  * Cache is empty
>  * Cache store contains non-null values for some keys
>  * invokeAll is invoked for those keys
> Update version is generated when update request reaches the primary node. 
> Then, we need to read-through stored values (the cache is empty) and pass 
> them to transformers. Since read-through changes entry version, subsequent 
> update fails with an assertion because read-through version is generated 
> later than update version.
> The scenario when a read-through is implemented via a separate loop with 
> innerGet() is possible only with invokeAll() because this is the only 
> multi-key cache operation that requires the previous entry value.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to