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 settings of cache group are cluster-wide and which are local-specific? In [1] I fixed only *rebalanceDelay *setting, what about *rebalanceOrder*? Lets compose a list of all local-specific settings in this thread. [1] https://issues.apache.org/jira/browse/IGNITE-5542 |
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 Chugunov <[hidden email]> wrote: > 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 settings of cache group are cluster-wide and which are > local-specific? > > In [1] I fixed only *rebalanceDelay *setting, what about *rebalanceOrder*? > > Lets compose a list of all local-specific settings in this thread. > > > [1] https://issues.apache.org/jira/browse/IGNITE-5542 > |
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 approach that node simply overrides local value on rebalanceMode with the one received from grid. Do you think this approach is reasonable? Wouldn't it be better to fail joining node if such inconsistency is detected? Thanks, Sergey. On Wed, Jul 19, 2017 at 4:27 PM, Semyon Boikov <[hidden email]> wrote: > 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 Chugunov < > [hidden email]> > wrote: > > > 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 settings of cache group are cluster-wide and which are > > local-specific? > > > > In [1] I fixed only *rebalanceDelay *setting, what about > *rebalanceOrder*? > > > > Lets compose a list of all local-specific settings in this thread. > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-5542 > > > |
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 <[hidden email] > wrote: > 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 approach that node simply overrides local value on > rebalanceMode with the one received from grid. > > Do you think this approach is reasonable? Wouldn't it be better to fail > joining node if such inconsistency is detected? > > Thanks, > Sergey. > > > On Wed, Jul 19, 2017 at 4:27 PM, Semyon Boikov <[hidden email]> > wrote: > > > 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 Chugunov < > > [hidden email]> > > wrote: > > > > > 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 settings of cache group are cluster-wide and which are > > > local-specific? > > > > > > In [1] I fixed only *rebalanceDelay *setting, what about > > *rebalanceOrder*? > > > > > > Lets compose a list of all local-specific settings in this thread. > > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-5542 > > > > > > |
Okay, I'll modify my code and let you know when everything will be ready
for review. On Thu, Jul 20, 2017 at 12:52 PM, Semyon Boikov <[hidden email]> wrote: > 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 < > [hidden email] > > wrote: > > > 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 approach that node simply overrides local value > on > > rebalanceMode with the one received from grid. > > > > Do you think this approach is reasonable? Wouldn't it be better to fail > > joining node if such inconsistency is detected? > > > > Thanks, > > Sergey. > > > > > > On Wed, Jul 19, 2017 at 4:27 PM, Semyon Boikov <[hidden email]> > > wrote: > > > > > 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 Chugunov < > > > [hidden email]> > > > wrote: > > > > > > > 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 settings of cache group are cluster-wide and which are > > > > local-specific? > > > > > > > > In [1] I fixed only *rebalanceDelay *setting, what about > > > *rebalanceOrder*? > > > > > > > > Lets compose a list of all local-specific settings in this thread. > > > > > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-5542 > > > > > > > > > > |
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 please proceed with review. On Thu, Jul 20, 2017 at 1:12 PM, Sergey Chugunov <[hidden email]> wrote: > Okay, I'll modify my code and let you know when everything will be ready > for review. > > On Thu, Jul 20, 2017 at 12:52 PM, Semyon Boikov <[hidden email]> > wrote: > >> 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 < >> [hidden email] >> > wrote: >> >> > 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 approach that node simply overrides local >> value on >> > rebalanceMode with the one received from grid. >> > >> > Do you think this approach is reasonable? Wouldn't it be better to fail >> > joining node if such inconsistency is detected? >> > >> > Thanks, >> > Sergey. >> > >> > >> > On Wed, Jul 19, 2017 at 4:27 PM, Semyon Boikov <[hidden email]> >> > wrote: >> > >> > > 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 Chugunov < >> > > [hidden email]> >> > > wrote: >> > > >> > > > 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 settings of cache group are cluster-wide and which are >> > > > local-specific? >> > > > >> > > > In [1] I fixed only *rebalanceDelay *setting, what about >> > > *rebalanceOrder*? >> > > > >> > > > Lets compose a list of all local-specific settings in this thread. >> > > > >> > > > >> > > > [1] https://issues.apache.org/jira/browse/IGNITE-5542 >> > > > >> > > >> > >> > > |
Free forum by Nabble | Edit this page |