[ 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:24 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]; # 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 registration? [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)