ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Artem Shutak (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (IGNITE-2645) Assertion error in ATOMIC cachce for invokeAll and cache store
Date Fri, 08 Apr 2016 16:49:25 GMT

    [ 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

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


> 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

View raw message