Yakov, I don't like the idea of intermixing changeable properties with constant ones in the configuration. Moreover, the standard configuration class is local to the node, while changing the config properties at runtime may be a distributed operation that needs to be propagated across the cluster.
How about we add getters and setters to IgniteConfigurationRuntime interface. BTW, this interface should also become an MBean, so it can be managed by external tools. D. On Tue, Aug 15, 2017 at 3:20 AM, Yakov Zhdanov <yzhda...@apache.org> wrote: > > I like the idea, but I am not sure how we will separate properties that > are > >dynamically changeable from the constant ones. > > Why do you want the separation? I thought having some annotation like > @RuntimeChangeSupported will be sufficient for documentation > > >Also, what is the API for updating these properties? Perhaps we can create > >a special interface, e.g. IgniteConfigurationRuntime (similar to Java > >Runtime class), which will have only setters and have all the properties > >that can be changed at runtime. > > The best way is to change the properties where they are configured, i.e. > use setters of configuration objects and setters of SPI's, etc. This most > likely will require stop using copy constructors for configurations. I > never liked that since it was sometimes the reason for stupid issues and we > do not do deep copy, e.g. SPIs and user provided factories are moved to the > copy as is. Moreover it is not 100% clear why it works this way for ages? > > I don't like separate interfaces with setters. How then should I get the > current updated values? Let's start from shorter list of easy to support > properties and see what issues we face. > > We also need to think over the propagation to newly started nodes. If new > nodes are started with a config file and some properties were updated at > runtime for current server topology. > > --Yakov >
