ascherbakov ok, thanks for the clarification.
gvvinblade hi! could you please check my fix suggestion in PR GitHub Pull Request #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), 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
[2] CachesRegistry.java#L52
[3] MvccProcessor.java#L211
ascherbakov,
Seems, ctx.kernalContext().coordinators().mvccEnabled() provides wrong result in this case.
Do we able to gain mvcc state on client topology somehow?