Vovan, We couldn't avoid API with cache configuration. Almost all of ~70 properties could be changed, some of them are instances of objects or could be user-defined class. Could you come up with alternatives for user-defined affinity function?
Also, the race would have a place in other scenarios. On Thu, Nov 22, 2018 at 8:50 AM Vladimir Ozerov <voze...@gridgain.com> wrote: > Ed, > > We may have API similar to “cache” and “getOrCreateCache”, or may not. It > is up to us to decide. Similarity on it’s own is weak argument. > Functionality and simplicity - this is what matters. > > Approach with cache configuration has three major issues > 1) It exposes properties which user will not be able to change, so typical > user actions would be: try to change property, fail as it is unsupported, > go reading documentation. Approach with separate POJO is intuitive and > self-documenting. > 2) It has race condition between config read and config apply, so user do > not know what exactly he changes, unless you change API to something like > “restartCaches(Tuple<CacheConfiguration, CacheConfiguration>...)”, which > user will need to call in a loop. > 3) And it is not suitable for non-Java platform, which is a showstopper - > all API should be available from all platforms unless it is proven to be > impossible to implement. > > Vladimir. > > чт, 22 нояб. 2018 г. в 1:06, Eduard Shangareev < > eduard.shangar...@gmail.com > >: > > > Vovan, > > > > Would you argue that we should have the similar API in Java as > > Ignite.cache(CacheConfiguration) or > > Ignite.getOrCreateCache(CacheConfiguration)? > > > > With a proposed solution, every other API call would rely on it finally. > > > > I am interested in having such feature not arguing about API > alternatives. > > > > We definitely should have the ability to change it via control.sh and > Java > > API. Everything else is optional from my point of view (at least on the > > current stage). > > > > Moreover, your arguments are more about our format of CacheConfiguration > > which couldn't be defined in other languages and clients. So, maybe we > > should start a discussion about how we should change it in 3.0? > > > > > > > > > > On Wed, Nov 21, 2018 at 7:45 PM Vladimir Ozerov <voze...@gridgain.com> > > wrote: > > > > > Ed, > > > > > > Why do we want to operate on CacheConfiguration so desperately? Your > > > example raises even more questions: > > > 1) What to do with thin clients? > > > 2) What to do with aforementioned race conditions, when cache could be > > > changed concurrently? > > > 3) Why such trivial operation from user perspective is only supported > > from > > > control.sh and not from the rest API (even Java client nodes will be > > > affected - remember our plans to remove requirement to have cache > classes > > > on client nodes, which is yet to be implemented). > > > > > > Compare it to alternative API: > > > > > > 1) Native call from any language without limitations: > > > > > > > > > Ignite.changeCache(CacheConfigurationChange.create().setCacheMode(REPLICATED).setBackups(2)); > > > > > > 2) Call from control.sh in one line without race conditions with > > concurrent > > > cache changes: > > > control.sh --cache --change cacheMode=REPLICATED backups=2 > > > > > > On Wed, Nov 21, 2018 at 7:32 PM Eduard Shangareev < > > > eduard.shangar...@gmail.com> wrote: > > > > > > > Vovan, > > > > > > > > user already is able to get cache configuration as xml. > > > > control.sh --cache list '.' --config > > > > > > > > So, user could update it and run: > > > > control.sh --cache --restart -cfg=xml.path > > > > > > > > > > > > On Wed, Nov 21, 2018 at 7:06 PM Vladimir Ozerov < > voze...@gridgain.com> > > > > wrote: > > > > > > > > > Ed, > > > > > > > > > > He can do that programmatically. But I meant another case - Java > node > > > > > creates a cache. Then .NET node wants to change it. Proposed API > > cannot > > > > > handle it. > > > > > > > > > > ср, 21 нояб. 2018 г. в 19:03, Eduard Shangareev < > > > > eshangar...@gridgain.com > > > > > >: > > > > > > > > > > > Vladimir, > > > > > > > > > > > > I didn't get how does .Net user start caches right now? XML and > > > remote > > > > > > node? Right? > > > > > > > > > > > > > > > > > > On Wed, Nov 21, 2018 at 6:55 PM Vladimir Ozerov < > > > voze...@gridgain.com> > > > > > > wrote: > > > > > > > > > > > > > Ed, > > > > > > > > > > > > > > We are not Java product. We support 6 platforms at the moment. > > Why > > > do > > > > > we > > > > > > > implement a feature which can only be used in Java, when it is > > very > > > > > easy > > > > > > to > > > > > > > make it available from everywhere? > > > > > > > > > > > > > > ср, 21 нояб. 2018 г. в 18:50, Eduard Shangareev < > > > > > > eshangar...@gridgain.com > > > > > > > >: > > > > > > > > > > > > > > > Vladimir, > > > > > > > > > > > > > > > > It would be Java API specific. > > > > > > > > For a user, we would add a new command for console.sh which > > would > > > > > take > > > > > > an > > > > > > > > XML-file path as a parameter. > > > > > > > > > > > > > > > > We could add other possibilities: for example, with the > builder > > > > which > > > > > > > would > > > > > > > > finally call this Ignite.restartCaches method. But it's nice > to > > > > have, > > > > > > > not a > > > > > > > > mandatory one. > > > > > > > > > > > > > > > > On Wed, Nov 21, 2018 at 6:43 PM Vladimir Ozerov < > > > > > voze...@gridgain.com> > > > > > > > > wrote: > > > > > > > > > > > > > > > > > Ed, > > > > > > > > > > > > > > > > > > Could you please demonstrate how .NET node or .NET will > > change > > > > > cache > > > > > > > > > configuration with proposed API? Taking in count that XML > is > > > not > > > > > > > > available > > > > > > > > > in most cases, and custom Java classes from cache > > configuration > > > > are > > > > > > > > > available only on server nodes and only from Java. > > > > > > > > > > > > > > > > > > ср, 21 нояб. 2018 г. в 18:36, Eduard Shangareev < > > > > > > > > > eduard.shangar...@gmail.com > > > > > > > > > >: > > > > > > > > > > > > > > > > > > > Vladimir, > > > > > > > > > > > > > > > > > > > > I don't see any difference here. > > > > > > > > > > > > > > > > > > > > The same possibilities would be available as with normal > > > cache > > > > > > start: > > > > > > > > > > -XML; > > > > > > > > > > -remote node. > > > > > > > > > > > > > > > > > > > > >3) Avoid race condition when configuration changes > between > > > > > > > > configuration > > > > > > > > > > read and method call (what could lead to a number of > > strange > > > > > > > effects). > > > > > > > > > > > > > > > > > > > > Well, we could add *old* configuration parameter for > > CAS-like > > > > > > > semantic. > > > > > > > > > > > > > > > > > > > > On Wed, Nov 21, 2018 at 6:26 PM Vladimir Ozerov < > > > > > > > voze...@gridgain.com> > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > Ed, > > > > > > > > > > > > > > > > > > > > > > Caches in .NET could be started programmatically, from > > XML > > > > > which > > > > > > > .NET > > > > > > > > > API > > > > > > > > > > > has no access to, or dynamically from remote nodes (eg > > Java > > > > > > node). > > > > > > > > > > > > > > > > > > > > > > ср, 21 нояб. 2018 г. в 18:24, Eduard Shangareev < > > > > > > > > > > > eduard.shangar...@gmail.com > > > > > > > > > > > >: > > > > > > > > > > > > > > > > > > > > > > > Vladimir, > > > > > > > > > > > > > > > > > > > > > > > > How does .Net user start caches right now? > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Nov 21, 2018 at 6:10 PM Vladimir Ozerov < > > > > > > > > > voze...@gridgain.com> > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > Best regards, > > > > > > > > Eduard. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Best regards, > > > > > > Eduard. > > > > > > > > > > > > > > > > > > > > >
