[
https://issues.apache.org/jira/browse/IGNITE-13051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17117499#comment-17117499
]
Maksim Timonin edited comment on IGNITE-13051 at 5/27/20, 8:26 AM:
-------------------------------------------------------------------
[~ascherbakov] ok, thanks for the clarification.
[~gvvinblade] hi! could you please check my fix suggestion in PR [GitHub Pull
Request #7852|https://github.com/apache/ignite/pull/7852]. Is it a right place
to fix? My logic is:
# By documentation [1] mvccEnabled is true whether at least one cache with
mvcc *registered*;
# Caches are *registered* in CachesRegistry [2] without applying
AttributeNodeFilter;
# MVCC flag set to true for new caches in next cases:
## preProcessCacheConfiguration: while dynamic starting cache;
## preProcessCacheConfiguration: adding cache from configuration;
## starting cache after triggering GlobalState to active.
# This bug describes a case:
## the cache is started on other nodes in MVCC mode;
## the cache would not be started on the node0 as it filtered by
AttributeNodeFilter;
## the cache is not added to configuration for the node0 IgniteConfiguration;
## so it leads that cache is registered on the node0, but not started and the
MVCC flag is not set. It leads to inconsistency of cache mode on different
nodes.
So I found a place to handle those nodes ([PR
fix|https://github.com/apache/ignite/pull/7852]), it already contains a handle
_initQueryStructuresForNotStartedCache._ So it looks like a right place to add
the MVCC handle there. But there are some questions:
# Is it valid to use _validateCacheConfiguration_ because by docs [3] it
validates caches before *start* but the cache won't be started?
# If MVCC enabled for registered caches, maybe it's better to check the MVCC
configuration while cache registration process?
[1]
[MvccProcessorImpl#L216|https://github.com/apache/ignite/blob/ignite-2.8.1/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/mvcc/MvccProcessorImpl.java#L216]
[2]
[CachesRegistry.java#L52|https://github.com/apache/ignite/blob/ignite-2.8.1/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/CachesRegistry.java#L52]
[3]
[MvccProcessor.java#L211|https://github.com/apache/ignite/blob/ignite-2.8.1/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/mvcc/MvccProcessor.java#L211]
was (Author: timonin.maksim):
[~ascherbakov] ok, thanks for the clarification.
[~gvvinblade] hi! could you please check my fix suggestion in PR [GitHub Pull
Request #7852|https://github.com/apache/ignite/pull/7852]. Is it a right place
to fix? My logic is:
# By documentation [1] mvccEnabled is true whether at least one cache with
mvcc *registered*;
# Caches are *registered* in CachesRegistry [2];
# MVCC flag set to true for new caches in next cases:
## preProcessCacheConfiguration: while dynamic starting cache;
## preProcessCacheConfiguration: adding cache from configuration;
## starting cache after triggering GlobalState to active.
# This bug describes a case:
## the cache is started on other nodes in MVCC mode;
## the cache would not be started on the node0 as it filtered by
AttributeNodeFilter;
## the cache is not added to configuration for the node0 IgniteConfiguration;
## so it leads that cache is registered on the node0, but not started and the
MVCC flag is not set. It leads to inconsistency of cache mode on different
nodes.
So I found a place to handle those nodes ([PR
fix|https://github.com/apache/ignite/pull/7852]), it already contains a handle
_initQueryStructuresForNotStartedCache._ So it looks like a right place to add
the MVCC handle there. But there are some questions:
# Is it valid to use _validateCacheConfiguration_ because by docs [3] it
validates caches before *start* but the cache won't be started?
# If MVCC enabled for registered caches, maybe it's better to check the MVCC
configuration while cache registration process?
[1]
[MvccProcessorImpl#L216|https://github.com/apache/ignite/blob/ignite-2.8.1/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/mvcc/MvccProcessorImpl.java#L216]
[2]
[CachesRegistry.java#L52|https://github.com/apache/ignite/blob/ignite-2.8.1/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/CachesRegistry.java#L52]
[3]
[MvccProcessor.java#L211|https://github.com/apache/ignite/blob/ignite-2.8.1/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/mvcc/MvccProcessor.java#L211]
> Optimized affinity switch on baseline node left is broken for client topology
> and MVCC
> --------------------------------------------------------------------------------------
>
> Key: IGNITE-13051
> URL: https://issues.apache.org/jira/browse/IGNITE-13051
> Project: Ignite
> Issue Type: Bug
> Reporter: Alexey Scherbakov
> Assignee: Maksim Timonin
> Priority: Critical
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If a node contains only client cache topology with MVCC enabled, PME will
> hang after changes introduced in IGNITE-12617.
> Reproduced by
> CachePartitionLossWithRestartsTest.testPartitionLossDetectionOnClientTopology[0
> false false -1] and enabled MVCC.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
