>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.
I don't 100% agree here. Let's discuss. 1. I would not mess with propagation for now. Propagation can be handled by special methods or by Visor/WebConsole 2. If we choose to create separate managing objects we end up in creating that for each configuration type we have now. And we have quite great number of config objects. For me personally, it seems more convenient to have configuration object a place to change and retrieve current configuration. We can have separate method to apply the changes (on configuration object or object that is configured by that configuration object). >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. Again, if we introduce separate runtime configurable object this seems to be very confusing. After I change the property via that object, should corresponding property change in let's say IgniteConfiguration? --Yakov
