Eduard, Got it. Please take the following things in count during design:
1) Two distinct PMEs might not work well. Consider a situation w1hen I decided to move a cache with index "MY_INDEX" from schema A to schema B. While cache was stopped, another cache with index "MY_INDEX" was created in schema B. Now first cache cannot start due to index name conflict. 2) Cancelling index creation is also bad idea because this is potentially long operation. Instead, most likely that we should wait to concurrent schema operations to finish first. That is, all operations on cache should be ordered wrt each other somehow 3) Why do we think that cache restart will be needed at all? We have a lot of configuration properties which could be changed safely either without PME or with a single PME. - rebalance properties, cache store properties (especially write-behind stuff), some query properties (e.g. "detail metrics"), etc.. In essence, it seems that >50% of properties could be changed without cache restart, other 25% will not be supported, and the rest may require restart. 4) Client nodes and thin client may not have necessary classes in classpath. E.g. consider a user which want to change rebalance timeout for cache, but do not have configured interceptor in classpath. With proposed API it will be impossible. This is especially true for non-Java clients. That said, I think we should consider another API which will not require full CacheConfiguration object. This might be a kind of builder or so. And once user set properties he want to change to the builder, we can analyze them and either change them in runtime without PME, change with a single PME or change with full cache restart. What do you think? Vladimir. On Wed, Nov 21, 2018 at 5:01 PM Eduard Shangareev <eshangar...@gridgain.com> wrote: > Vladimir, > > 1) Affinity could be changed, but count of partition couldn't be. > 2) So it would trigger 2 PME. Dynamic start and stop. > 3) In theory, should cancel them and new setting should be applied. How it > works now? Create an index and stop node, for example. > > On Wed, Nov 21, 2018 at 4:56 PM Vladimir Ozerov <voze...@gridgain.com> > wrote: > > > Hi Ed, > > > > Several questions from my side: > > 1) If we do not allow to change the most demanded by users things like > > affinity or persistence/in-memory, then what kind of configuration > > properties do we expect to be changed? Can we have several examples? > > 2) How will it interact with PME? > > 3) How will it interact with CREATE INDEX and ALTER TABLE commands? > > > > On Wed, Nov 21, 2018 at 4:48 PM Eduard Shangareev < > > eduard.shangar...@gmail.com> wrote: > > > > > Igniters, > > > > > > I propose new public API to change the cache configuration of > persistent > > > caches with keeping data. > > > > > > It would look like: > > > > > > Ignite ignite = ...; > > > ignite.restartCaches(cfg1, ... cfgN); > > > > > > where cfgX is a new cache configuration, which contains the name of an > > > existing persistent cache. > > > > > > The obvious limitation: > > > - affinity key mapping couldn't be changed; > > > - count of partitions couldn't be changed; > > > - MVCC couldn't be turned off/on; > > > - persistent couldn't be turned off; > > > - group settings couldn't be changed (group name); > > > - if cache belongs to group it's needed to restart all of them. > > > > > > Failure scenario is the crucial thing (and most difficult): > > > - initiator fail; > > > - cluster restart at any stage; > > > - joining/starting offline nodes. > > > > > > Some thoughts about implementation: > > > - stop cache with destroy=false; > > > - start cache dynamically with new configuration; > > > - if indexes settings changed - remove index.bin to start indexation; > > > - change blt-history when start cache initiated to not allow join nodes > > > with old configuration; > > > - use restartId (IGNITE-8911) to not allow to start cache in between. > > > > > > Your thoughts? Would it be a useful feature? > > > > > > > > -- > Best regards, > Eduard. >
