You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Andrey Mashenkov (Jira)" <ji...@apache.org> on 2022/06/08 16:19:00 UTC
[jira] [Updated] (IGNITE-17123) Fix wrong update counter assignment on backup nodes for noop invoke operation.
[ https://issues.apache.org/jira/browse/IGNITE-17123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andrey Mashenkov updated IGNITE-17123:
--------------------------------------
Summary: Fix wrong update counter assignment on backup nodes for noop invoke operation. (was: Optimize update counter assignment on backup nodes.)
> Fix wrong update counter assignment on backup nodes for noop invoke operation.
> ------------------------------------------------------------------------------
>
> Key: IGNITE-17123
> URL: https://issues.apache.org/jira/browse/IGNITE-17123
> Project: Ignite
> Issue Type: Improvement
> Components: cache
> Reporter: Andrey Mashenkov
> Assignee: Andrey Mashenkov
> Priority: Minor
> Fix For: 2.14
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Transaction reserves partition counters on primary.
> On the backup side, TxEntries must be commited with counters from the reserved range.
> However, a range of update counters, which were reserved on primary, is NOT validated on backup. Thus means NOOP invoke operation may cause partition counter difference on the primary and backup nodes.
> 1. Let's pass NOOP result of invoke operation to the backup and avoid incorrect partition counter change on backup nodes (see DhtTxPrepareFuture).
> 2. Update counter can be assigned to TxEntry instantly on tx commit on Remote node (for the WAL purposes) instead of allocating+iterating over a new collection (see GridDistributedTxRemoteAdapter.commitIfLocked).
--
This message was sent by Atlassian Jira
(v8.20.7#820007)