Eduard, Simple != correct. Let’s consider a simple use case: user want to change PARTITIONED -> REPLICATED from .NET, but do not some classes from CacheConfiguration. How do we solve this?
Vladimir. ср, 21 нояб. 2018 г. в 18:02, Eduard Shangareev <eduard.shangar...@gmail.com >: > Vladimir, > > I propose not to change cache configuration in runtime but restart cache > with the new compatible configuration on data which we have underfoot. > > What we could change: > -backup count; > -TRANSACTIONAL <-> ATOMIC; > -REPLICATED - PARTITIONED; > -other settings. > > So, yeah, it would be great to have a possibility to change some properties > in runtime. But right we don't any way to change anything except indexes > and SQL fields. > > We already have all mechanism to do this. > The main issue is to make it reliable and exclude cases when we could come > to the unrecoverable state. > > So, I suggest keeping the solution as simple as possible. > For indexes clashes and ClassNotFoundException we could revert > configuration update and start with the old configuration. > > > On Wed, Nov 21, 2018 at 5:44 PM Vladimir Ozerov <voze...@gridgain.com> > wrote: > > > 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. > > > > > >
