Re: Local-specific vs cluster-wide configuration setting for cache groups

Semen, I examined code and found out that such check already exists: node cannot join cluster if it has rebalanceMode setting inconsistent with other nodes in the cluster. I also found a test for it, it is called *GridCacheConfigurationValidationSelfTest*. No changes to my code are needed, so

Re: Local-specific vs cluster-wide configuration setting for cache groups

Let's treat consistency of rebalanceMode as critical (this really can cause problems if one node has rebalanceMode NONE and other SYNC or ASYNC). Thanks On Thu, Jul 20, 2017 at 12:46 PM, Sergey Chugunov wrote: > Semen, > > What about attribute *rebalanceMode*? From

Re: Local-specific vs cluster-wide configuration setting for cache groups

Semen, What about attribute *rebalanceMode*? From *ClusterCachesInfo::validateCacheGroupConfiguration* I see that consistency of the attribute is treated as critical and node even fails to start if different caches in the same group have different rebalanceMode setting. I've already implemented

Re: Local-specific vs cluster-wide configuration setting for cache groups

Hi Sergey, I don't think that this really will be needed, but let's allow for local config to override all 'rebalanceXXX' properties. Also please make sure we print warning if any of these properties differs from config received from grid. Thanks! On Fri, Jul 14, 2017 at 2:04 PM, Sergey

Local-specific vs cluster-wide configuration setting for cache groups

Hello folks, Investigating failing test [1] I found that cache group setting *rebalanceDelay *was rewritten on joining node by configuration received from the grid when it supposed to be local-specific. I fixed this and test resumed passing, but I have a broader question: which configuration