Guys, Why not to let user to decide whether to persist changed properties or not? We could have a Boolean flag on API "persist=true|false".
Make sense? On Tue, Aug 22, 2017 at 6:52 AM, Dmitriy Setrakyan <[email protected]> wrote: > On Mon, Aug 21, 2017 at 7:28 AM, Alexey Dmitriev <[email protected]> > wrote: > > > I believe it should be persistent. > > We can have a parameter about "reset configuration on restart", which can > > be also OLCC-compatible > > > > Alexey, the problem with persisting at all times is that some properties > may be set directly from code. What is wrong with persisting when user > explicitly calls saveToFile method? > > > > > > On Mon, Aug 21, 2017 at 5:22 PM, Dmitriy Setrakyan < > [email protected]> > > wrote: > > > > > On Mon, Aug 21, 2017 at 7:15 AM, Alexey Dmitriev < > [email protected] > > > > > > wrote: > > > > > > > I would say it should as soon as we moving to "persistence". > > > > It will require to look at the things a bit different than before, > but > > I > > > > would say that's an evolution for the product. > > > > We probably also should think how our configuration system should be > > > > changed to make it more obvious. > > > > > > > > > > But in that case, what to do with XML configuration? Should it be > updated > > > as well? Or even worse, what if user added configuration from code? > > > > > > On Mon, Aug 21, 2017 at 5:11 PM, Dmitriy Setrakyan < > > [email protected]> > > > > wrote: > > > > > > > > > I think the main question I have is whether this configuration > change > > > > will > > > > > survive restarts. Part of me says it should, and the other part > says > > it > > > > > shouldn't. > > > > > > > > > > Does anyone have a strong opinion about this? > > > > > > > > > > D. > > > > > > > > > > On Mon, Aug 21, 2017 at 7:07 AM, Alexey Dmitriev < > > > [email protected] > > > > > > > > > > wrote: > > > > > > > > > > > It looks like very useful and natural thing having the parameters > > > > change > > > > > on > > > > > > the fly. > > > > > > Maybe we should design something like OLCC (on-line configuration > > > > change) > > > > > > module, which will request different procedures for different > bunch > > > of > > > > > > parameters. > > > > > > All the parameters, this way, will be splitted into several > groups. > > > > > > For example in the worst case, when all the grid has to be > > > synchronized > > > > > for > > > > > > particular parameter change, some preparation on the grid has to > be > > > > > > performed, than when all the nodes reports readiness, the > parameter > > > > > change > > > > > > could be initiated. > > > > > > On the opposite if it is parameter configured per node, OLCC > state > > > > > machine > > > > > > will work simpler without inter-node communication. > > > > > > > > > > > > On Mon, Aug 21, 2017 at 4:21 PM, Yakov Zhdanov < > > [email protected]> > > > > > > wrote: > > > > > > > > > > > > > >I see your point. In this case, we should have a special > package > > > > > > > containing > > > > > > > >all the runtime config properties. > > > > > > > > > > > > > > Dmitry, I think this will be a mess. > > > > > > > > > > > > > > Igniters, any more opinions? > > > > > > > > > > > > > > --Yakov > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Alexey Dmitriev, VP Engineering > > > > > > *GridGain Systems* > > > > > > www.gridgain.com > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Alexey Dmitriev, VP Engineering > > > > *GridGain Systems* > > > > www.gridgain.com > > > > > > > > > > > > > > > -- > > Alexey Dmitriev, VP Engineering > > *GridGain Systems* > > www.gridgain.com > > > -- Alexey Kuznetsov
