[
https://issues.apache.org/jira/browse/IGNITE-10078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16845094#comment-16845094
]
Ivan Rakov commented on IGNITE-10078:
-------------------------------------
Overall looks good.
1)
org/apache/ignite/internal/processors/cache/CacheAffinitySharedManager.java:1728
- IgniteCheckedException is never thrown
2)
org/apache/ignite/internal/processors/cache/distributed/dht/topology/GridDhtPartitionTopologyImpl.java:482
- please add @param tag description
3)
org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl#finalizeUpdateCounters
- this logic needs documentation or comments. why do we need to log this set
of rollback records? why "gapStart - 1" and "gapStop - gapStart + 1".
4) How https://issues.apache.org/jira/browse/IGNITE-11797 and
IgniteCacheGroupsTest are related? If scenario is not working until issue is
resolved, perhaps we should mute tests.
5) The same with https://issues.apache.org/jira/browse/IGNITE-11791 and
IgnitePdsContinuousRestartTestWithExpiryPolicy
6) Please add javadoc to CacheAffinitySharedManager#addToWaitGroup. What does
this method do?
7) CacheContinuousQueryHandler - there are unused imports
8) Please add class description for MetastoreDataPageIO
9) I think, we should expand javadoc for PartitionUpdateCounter (or for
PartitionTxUpdateCounterImpl, if t's applicable only for this instance). From
doc it's understood what are LWM and HWM, but their flow in cluster is still
unclear. Let's add brief description of counters flow between backup and
primary (which counters are generated / sent to remote node on each case),
maybe with examples.
Please fix minor comments mentioned above, recheck tests that failed in
previous bot comment and then proceed to merge.
> Node failure during concurrent partition updates may cause partition desync
> between primary and backup.
> -------------------------------------------------------------------------------------------------------
>
> Key: IGNITE-10078
> URL: https://issues.apache.org/jira/browse/IGNITE-10078
> Project: Ignite
> Issue Type: Bug
> Reporter: Alexei Scherbakov
> Assignee: Alexei Scherbakov
> Priority: Major
> Fix For: 2.8
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> This is possible if some updates are not written to WAL before node failure.
> They will be not applied by rebalancing due to same partition counters in
> certain scenario:
> 1. Start grid with 3 nodes, 2 backups.
> 2. Preload some data to partition P.
> 3. Start two concurrent transactions writing single key to the same partition
> P, keys are different
> {noformat}
> try(Transaction tx = client.transactions().txStart(PESSIMISTIC,
> REPEATABLE_READ, 0, 1)) {
> client.cache(DEFAULT_CACHE_NAME).put(k, v);
> tx.commit();
> }
> {noformat}
> 4. Order updates on backup in the way such update with max partition counter
> is written to WAL and update with lesser partition counter failed due to
> triggering of FH before it's added to WAL
> 5. Return failed node to grid, observe no rebalancing due to same partition
> counters.
> Possible solution: detect gaps in update counters on recovery and force
> rebalance from a node without gaps if detected.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
