New API for changing configuration of persistent caches

[Eduard Shangareev]

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 <[hidden email]>
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 <[hidden email]
> >:
>
> > 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 <[hidden email]>
> > 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 <
> > [hidden email]
> > > >:
> > >
> > > > 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 <
> [hidden email]>
> > > > 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 <
> > > > > [hidden email]
> > > > > >:
> > > > >
> > > > > > 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 <
> > > [hidden email]>
> > > > > > 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 <
> > > > > > > [hidden email]
> > > > > > > >:
> > > > > > >
> > > > > > > > Vladimir,
> > > > > > > >
> > > > > > > > How does .Net user start caches right now?
> > > > > > > >
> > > > > > > > On Wed, Nov 21, 2018 at 6:10 PM Vladimir Ozerov <
> > > > > [hidden email]>
> > > > > > > > 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 <
> > > > > > > > > [hidden email]
> > > > > > > > > >:
> > > > > > > > >
> > > > > > > > > > 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 <
> > > > > > > [hidden email]>
> > > > > > > > > > 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 <
> > > > > > > > > > > [hidden email]>
> > > > > > > > > > > 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 <
> > > > > > > > > [hidden email]>
> > > > > > > > > > > > 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 <
> > > > > > > > > > > > > [hidden email]> 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.
> >
>

[Dmitry Pavlov]

By the very first look, a new method can work absolutely the same with
cache() & getOrCreateCache() - it will be easy to follow by users.

Vladimir, could you give an example of API you proposing to implement?

ср, 21 нояб. 2018 г. в 19:32, Eduard Shangareev <[hidden email]
>:

> 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 <[hidden email]>
> 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 <
> [hidden email]
> > >:
> >
> > > 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 <[hidden email]>
> > > 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 <
> > > [hidden email]
> > > > >:
> > > >
> > > > > 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 <
> > [hidden email]>
> > > > > 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 <
> > > > > > [hidden email]
> > > > > > >:
> > > > > >
> > > > > > > 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 <
> > > > [hidden email]>
> > > > > > > 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 <
> > > > > > > > [hidden email]
> > > > > > > > >:
> > > > > > > >
> > > > > > > > > Vladimir,
> > > > > > > > >
> > > > > > > > > How does .Net user start caches right now?
> > > > > > > > >
> > > > > > > > > On Wed, Nov 21, 2018 at 6:10 PM Vladimir Ozerov <
> > > > > > [hidden email]>
> > > > > > > > > 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 <
> > > > > > > > > > [hidden email]
> > > > > > > > > > >:
> > > > > > > > > >
> > > > > > > > > > > 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 <
> > > > > > > > [hidden email]>
> > > > > > > > > > > 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 <
> > > > > > > > > > > > [hidden email]>
> > > > > > > > > > > > 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 <
> > > > > > > > > > [hidden email]>
> > > > > > > > > > > > > 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 <
> > > > > > > > > > > > > > [hidden email]> 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.
> > >
> >
>

[Vladimir Ozerov]

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 <
[hidden email]> 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 <[hidden email]>
> 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 <
> [hidden email]
> > >:
> >
> > > 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 <[hidden email]>
> > > 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 <
> > > [hidden email]
> > > > >:
> > > >
> > > > > 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 <
> > [hidden email]>
> > > > > 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 <
> > > > > > [hidden email]
> > > > > > >:
> > > > > >
> > > > > > > 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 <
> > > > [hidden email]>
> > > > > > > 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 <
> > > > > > > > [hidden email]
> > > > > > > > >:
> > > > > > > >
> > > > > > > > > Vladimir,
> > > > > > > > >
> > > > > > > > > How does .Net user start caches right now?
> > > > > > > > >
> > > > > > > > > On Wed, Nov 21, 2018 at 6:10 PM Vladimir Ozerov <
> > > > > > [hidden email]>
> > > > > > > > > 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 <
> > > > > > > > > > [hidden email]
> > > > > > > > > > >:
> > > > > > > > > >
> > > > > > > > > > > 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 <
> > > > > > > > [hidden email]>
> > > > > > > > > > > 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 <
> > > > > > > > > > > > [hidden email]>
> > > > > > > > > > > > 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 <
> > > > > > > > > > [hidden email]>
> > > > > > > > > > > > > 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 <
> > > > > > > > > > > > > > [hidden email]> 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.
> > >
> >
>

[Eduard Shangareev]

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 <[hidden email]>
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 <
> [hidden email]> 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 <[hidden email]>
> > 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 <
> > [hidden email]
> > > >:
> > >
> > > > 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 <
> [hidden email]>
> > > > 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 <
> > > > [hidden email]
> > > > > >:
> > > > >
> > > > > > 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 <
> > > [hidden email]>
> > > > > > 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 <
> > > > > > > [hidden email]
> > > > > > > >:
> > > > > > >
> > > > > > > > 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 <
> > > > > [hidden email]>
> > > > > > > > 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 <
> > > > > > > > > [hidden email]
> > > > > > > > > >:
> > > > > > > > >
> > > > > > > > > > Vladimir,
> > > > > > > > > >
> > > > > > > > > > How does .Net user start caches right now?
> > > > > > > > > >
> > > > > > > > > > On Wed, Nov 21, 2018 at 6:10 PM Vladimir Ozerov <
> > > > > > > [hidden email]>
> > > > > > > > > > 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 <
> > > > > > > > > > > [hidden email]
> > > > > > > > > > > >:
> > > > > > > > > > >
> > > > > > > > > > > > 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 <
> > > > > > > > > [hidden email]>
> > > > > > > > > > > > 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 <
> > > > > > > > > > > > > [hidden email]>
> > > > > > > > > > > > > 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 <
> > > > > > > > > > > [hidden email]>
> > > > > > > > > > > > > > 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 <
> > > > > > > > > > > > > > > [hidden email]> 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.
> > > >
> > >
> >
>

[Vladimir Ozerov]

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 <[hidden email]
>:

> 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 <[hidden email]>
> 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 <
> > [hidden email]> 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 <[hidden email]>
> > > 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 <
> > > [hidden email]
> > > > >:
> > > >
> > > > > 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 <
> > [hidden email]>
> > > > > 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 <
> > > > > [hidden email]
> > > > > > >:
> > > > > >
> > > > > > > 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 <
> > > > [hidden email]>
> > > > > > > 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 <
> > > > > > > > [hidden email]
> > > > > > > > >:
> > > > > > > >
> > > > > > > > > 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 <
> > > > > > [hidden email]>
> > > > > > > > > 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 <
> > > > > > > > > > [hidden email]
> > > > > > > > > > >:
> > > > > > > > > >
> > > > > > > > > > > Vladimir,
> > > > > > > > > > >
> > > > > > > > > > > How does .Net user start caches right now?
> > > > > > > > > > >
> > > > > > > > > > > On Wed, Nov 21, 2018 at 6:10 PM Vladimir Ozerov <
> > > > > > > > [hidden email]>
> > > > > > > > > > > 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 <
> > > > > > > > > > > > [hidden email]
> > > > > > > > > > > > >:
> > > > > > > > > > > >
> > > > > > > > > > > > > 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 <
> > > > > > > > > > [hidden email]>
> > > > > > > > > > > > > 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 <
> > > > > > > > > > > > > > [hidden email]>
> > > > > > > > > > > > > > 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 <
> > > > > > > > > > > > [hidden email]>
> > > > > > > > > > > > > > > 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 <
> > > > > > > > > > > > > > > > [hidden email]> 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.
> > > > >
> > > >
> > >
> >
>

[Eduard Shangareev]

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 <[hidden email]>
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 <
> [hidden email]
> >:
>
> > 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 <[hidden email]>
> > 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 <
> > > [hidden email]> 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 <
> [hidden email]>
> > > > 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 <
> > > > [hidden email]
> > > > > >:
> > > > >
> > > > > > 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 <
> > > [hidden email]>
> > > > > > 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 <
> > > > > > [hidden email]
> > > > > > > >:
> > > > > > >
> > > > > > > > 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 <
> > > > > [hidden email]>
> > > > > > > > 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 <
> > > > > > > > > [hidden email]
> > > > > > > > > >:
> > > > > > > > >
> > > > > > > > > > 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 <
> > > > > > > [hidden email]>
> > > > > > > > > > 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 <
> > > > > > > > > > > [hidden email]
> > > > > > > > > > > >:
> > > > > > > > > > >
> > > > > > > > > > > > Vladimir,
> > > > > > > > > > > >
> > > > > > > > > > > > How does .Net user start caches right now?
> > > > > > > > > > > >
> > > > > > > > > > > > On Wed, Nov 21, 2018 at 6:10 PM Vladimir Ozerov <
> > > > > > > > > [hidden email]>
> > > > > > > > > > > > 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 <
> > > > > > > > > > > > > [hidden email]
> > > > > > > > > > > > > >:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > 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 <
> > > > > > > > > > > [hidden email]>
> > > > > > > > > > > > > > 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 <
> > > > > > > > > > > > > > > [hidden email]>
> > > > > > > > > > > > > > > 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 <
> > > > > > > > > > > > > [hidden email]>
> > > > > > > > > > > > > > > > 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 <
> > > > > > > > > > > > > > > > > [hidden email]> 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.
> > > > > >
> > > > >
> > > >
> > >
> >
>

[Vladimir Ozerov]

My variant of API avoids cache configuration.

One more thing to note - as we found out control.sh cannot dump XML
configuration. Currently it returns only subset of properties. And in
general case it is impossible to convert CacheConfiguration to Spring XML,
because Spring XMLis not serialization protocol. So API with
CacheConfiguration doesn’t seem to work for control.sh as well.

чт, 22 нояб. 2018 г. в 10:05, Eduard Shangareev <[hidden email]
>:

> 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 <[hidden email]>
> 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 <
> > [hidden email]
> > >:
> >
> > > 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 <[hidden email]>
> > > 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 <
> > > > [hidden email]> 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 <
> > [hidden email]>
> > > > > 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 <
> > > > > [hidden email]
> > > > > > >:
> > > > > >
> > > > > > > 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 <
> > > > [hidden email]>
> > > > > > > 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 <
> > > > > > > [hidden email]
> > > > > > > > >:
> > > > > > > >
> > > > > > > > > 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 <
> > > > > > [hidden email]>
> > > > > > > > > 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 <
> > > > > > > > > > [hidden email]
> > > > > > > > > > >:
> > > > > > > > > >
> > > > > > > > > > > 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 <
> > > > > > > > [hidden email]>
> > > > > > > > > > > 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 <
> > > > > > > > > > > > [hidden email]
> > > > > > > > > > > > >:
> > > > > > > > > > > >
> > > > > > > > > > > > > Vladimir,
> > > > > > > > > > > > >
> > > > > > > > > > > > > How does .Net user start caches right now?
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Wed, Nov 21, 2018 at 6:10 PM Vladimir Ozerov <
> > > > > > > > > > [hidden email]>
> > > > > > > > > > > > > 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 <
> > > > > > > > > > > > > > [hidden email]
> > > > > > > > > > > > > > >:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 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 <
> > > > > > > > > > > > [hidden email]>
> > > > > > > > > > > > > > > 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 <
> > > > > > > > > > > > > > > > [hidden email]>
> > > > > > > > > > > > > > > > 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 <
> > > > > > > > > > > > > > [hidden email]>
> > > > > > > > > > > > > > > > > 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 <
> > > > > > > > > > > > > > > > > > [hidden email]> 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.
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

[Eduard Shangareev]

I don't see how you variant handles user-defined objects (factories,
affinity-functions, interceptors, etc.). Could you describe?

On Thu, Nov 22, 2018 at 10:47 AM Vladimir Ozerov <[hidden email]>
wrote:

> My variant of API avoids cache configuration.
>
> One more thing to note - as we found out control.sh cannot dump XML
> configuration. Currently it returns only subset of properties. And in
> general case it is impossible to convert CacheConfiguration to Spring XML,
> because Spring XMLis not serialization protocol. So API with
> CacheConfiguration doesn’t seem to work for control.sh as well.
>
> чт, 22 нояб. 2018 г. в 10:05, Eduard Shangareev <
> [hidden email]
> >:
>
> > 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 <[hidden email]>
> > 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 <
> > > [hidden email]
> > > >:
> > >
> > > > 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 <
> [hidden email]>
> > > > 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 <
> > > > > [hidden email]> 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 <
> > > [hidden email]>
> > > > > > 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 <
> > > > > > [hidden email]
> > > > > > > >:
> > > > > > >
> > > > > > > > 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 <
> > > > > [hidden email]>
> > > > > > > > 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 <
> > > > > > > > [hidden email]
> > > > > > > > > >:
> > > > > > > > >
> > > > > > > > > > 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 <
> > > > > > > [hidden email]>
> > > > > > > > > > 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 <
> > > > > > > > > > > [hidden email]
> > > > > > > > > > > >:
> > > > > > > > > > >
> > > > > > > > > > > > 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 <
> > > > > > > > > [hidden email]>
> > > > > > > > > > > > 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 <
> > > > > > > > > > > > > [hidden email]
> > > > > > > > > > > > > >:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Vladimir,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > How does .Net user start caches right now?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Wed, Nov 21, 2018 at 6:10 PM Vladimir Ozerov <
> > > > > > > > > > > [hidden email]>
> > > > > > > > > > > > > > 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 <
> > > > > > > > > > > > > > > [hidden email]
> > > > > > > > > > > > > > > >:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 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 <
> > > > > > > > > > > > > [hidden email]>
> > > > > > > > > > > > > > > > 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 <
> > > > > > > > > > > > > > > > > [hidden email]>
> > > > > > > > > > > > > > > > > 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 <
> > > > > > > > > > > > > > > [hidden email]>
> > > > > > > > > > > > > > > > > > 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 <
> > > > > > > > > > > > > > > > > > > [hidden email]> 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.
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

[Denis Mekhanikov]

Guys,

I like the idea with the configuration builder more.
We could limit the set of properties by providing only modifiable ones in
the builder interface.
Otherwise only runtime will show whether you tried to modify a proper
setting.
And if we decide to make another property modifiable, then we will just add
more methods to the builder interface,
so users won't need to remember, which properties in which versions are
available for change.

We should think about possibility to change a data region for a cache.
This is a valid use-case, when you realize, that data in your cache
occupies too mush space,
so you want it to become persistent.
Allowing to change data region configuration on nodes in run-time would be
ideal,
but it's outside of the scope of the proposed change.

Denis

чт, 22 нояб. 2018 г. в 11:30, Eduard Shangareev <[hidden email]
>:

> I don't see how you variant handles user-defined objects (factories,
> affinity-functions, interceptors, etc.). Could you describe?
>
> On Thu, Nov 22, 2018 at 10:47 AM Vladimir Ozerov <[hidden email]>
> wrote:
>
> > My variant of API avoids cache configuration.
> >
> > One more thing to note - as we found out control.sh cannot dump XML
> > configuration. Currently it returns only subset of properties. And in
> > general case it is impossible to convert CacheConfiguration to Spring
> XML,
> > because Spring XMLis not serialization protocol. So API with
> > CacheConfiguration doesn’t seem to work for control.sh as well.
> >
> > чт, 22 нояб. 2018 г. в 10:05, Eduard Shangareev <
> > [hidden email]
> > >:
> >
> > > 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 <[hidden email]>
> > > 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 <
> > > > [hidden email]
> > > > >:
> > > >
> > > > > 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 <
> > [hidden email]>
> > > > > 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 <
> > > > > > [hidden email]> 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 <
> > > > [hidden email]>
> > > > > > > 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 <
> > > > > > > [hidden email]
> > > > > > > > >:
> > > > > > > >
> > > > > > > > > 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 <
> > > > > > [hidden email]>
> > > > > > > > > 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 <
> > > > > > > > > [hidden email]
> > > > > > > > > > >:
> > > > > > > > > >
> > > > > > > > > > > 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 <
> > > > > > > > [hidden email]>
> > > > > > > > > > > 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 <
> > > > > > > > > > > > [hidden email]
> > > > > > > > > > > > >:
> > > > > > > > > > > >
> > > > > > > > > > > > > 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 <
> > > > > > > > > > [hidden email]>
> > > > > > > > > > > > > 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 <
> > > > > > > > > > > > > > [hidden email]
> > > > > > > > > > > > > > >:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Vladimir,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > How does .Net user start caches right now?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Wed, Nov 21, 2018 at 6:10 PM Vladimir
> Ozerov <
> > > > > > > > > > > > [hidden email]>
> > > > > > > > > > > > > > > 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 <
> > > > > > > > > > > > > > > > [hidden email]
> > > > > > > > > > > > > > > > >:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 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 <
> > > > > > > > > > > > > > [hidden email]>
> > > > > > > > > > > > > > > > > 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 <
> > > > > > > > > > > > > > > > > > [hidden email]>
> > > > > > > > > > > > > > > > > > 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 <
> > > > > > > > > > > > > > > > [hidden email]>
> > > > > > > > > > > > > > > > > > > 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 <
> > > > > > > > > > > > > > > > > > > > [hidden email]> 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.
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

[Vladimir Ozerov]

Ed,

We have ~70 properties in CacheConfiguration. ~50 of them are plain, ~20
are custom classes. My variant allows to change plain properties from any
platform, and the rest 20 from any platform when user has relevant
BinaryType.

On Thu, Nov 22, 2018 at 11:30 AM Eduard Shangareev <
[hidden email]> wrote:

> I don't see how you variant handles user-defined objects (factories,
> affinity-functions, interceptors, etc.). Could you describe?
>
> On Thu, Nov 22, 2018 at 10:47 AM Vladimir Ozerov <[hidden email]>
> wrote:
>
> > My variant of API avoids cache configuration.
> >
> > One more thing to note - as we found out control.sh cannot dump XML
> > configuration. Currently it returns only subset of properties. And in
> > general case it is impossible to convert CacheConfiguration to Spring
> XML,
> > because Spring XMLis not serialization protocol. So API with
> > CacheConfiguration doesn’t seem to work for control.sh as well.
> >
> > чт, 22 нояб. 2018 г. в 10:05, Eduard Shangareev <
> > [hidden email]
> > >:
> >
> > > 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 <[hidden email]>
> > > 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 <
> > > > [hidden email]
> > > > >:
> > > >
> > > > > 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 <
> > [hidden email]>
> > > > > 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 <
> > > > > > [hidden email]> 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 <
> > > > [hidden email]>
> > > > > > > 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 <
> > > > > > > [hidden email]
> > > > > > > > >:
> > > > > > > >
> > > > > > > > > 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 <
> > > > > > [hidden email]>
> > > > > > > > > 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 <
> > > > > > > > > [hidden email]
> > > > > > > > > > >:
> > > > > > > > > >
> > > > > > > > > > > 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 <
> > > > > > > > [hidden email]>
> > > > > > > > > > > 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 <
> > > > > > > > > > > > [hidden email]
> > > > > > > > > > > > >:
> > > > > > > > > > > >
> > > > > > > > > > > > > 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 <
> > > > > > > > > > [hidden email]>
> > > > > > > > > > > > > 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 <
> > > > > > > > > > > > > > [hidden email]
> > > > > > > > > > > > > > >:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Vladimir,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > How does .Net user start caches right now?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Wed, Nov 21, 2018 at 6:10 PM Vladimir
> Ozerov <
> > > > > > > > > > > > [hidden email]>
> > > > > > > > > > > > > > > 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 <
> > > > > > > > > > > > > > > > [hidden email]
> > > > > > > > > > > > > > > > >:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 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 <
> > > > > > > > > > > > > > [hidden email]>
> > > > > > > > > > > > > > > > > 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 <
> > > > > > > > > > > > > > > > > > [hidden email]>
> > > > > > > > > > > > > > > > > > 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 <
> > > > > > > > > > > > > > > > [hidden email]>
> > > > > > > > > > > > > > > > > > > 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 <
> > > > > > > > > > > > > > > > > > > > [hidden email]> 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.
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

[Eduard Shangareev]

Ok,

We need two approaches to change cache configuration:
1. Ignite.restartCaches(CacheConfiguration ... cfgs);
2. Ignite.restartCaches(CacheConfigurationDiff ... cfgDiffs);

Also, we need some versioning of cache configurations for caches. Which
could be done when we move the cache configuration from serialized file to
metastore.

It is necessary for several failover scenarios (actually, all of them
include joining node with outdated configuration).
And for CAS-like API for restarting caches.


On Thu, Nov 22, 2018 at 12:19 PM Vladimir Ozerov <[hidden email]>
wrote:

> Ed,
>
> We have ~70 properties in CacheConfiguration. ~50 of them are plain, ~20
> are custom classes. My variant allows to change plain properties from any
> platform, and the rest 20 from any platform when user has relevant
> BinaryType.
>
> On Thu, Nov 22, 2018 at 11:30 AM Eduard Shangareev <
> [hidden email]> wrote:
>
> > I don't see how you variant handles user-defined objects (factories,
> > affinity-functions, interceptors, etc.). Could you describe?
> >
> > On Thu, Nov 22, 2018 at 10:47 AM Vladimir Ozerov <[hidden email]>
> > wrote:
> >
> > > My variant of API avoids cache configuration.
> > >
> > > One more thing to note - as we found out control.sh cannot dump XML
> > > configuration. Currently it returns only subset of properties. And in
> > > general case it is impossible to convert CacheConfiguration to Spring
> > XML,
> > > because Spring XMLis not serialization protocol. So API with
> > > CacheConfiguration doesn’t seem to work for control.sh as well.
> > >
> > > чт, 22 нояб. 2018 г. в 10:05, Eduard Shangareev <
> > > [hidden email]
> > > >:
> > >
> > > > 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 <
> [hidden email]>
> > > > 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 <
> > > > > [hidden email]
> > > > > >:
> > > > >
> > > > > > 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 <
> > > [hidden email]>
> > > > > > 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 <
> > > > > > > [hidden email]> 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 <
> > > > > [hidden email]>
> > > > > > > > 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 <
> > > > > > > > [hidden email]
> > > > > > > > > >:
> > > > > > > > >
> > > > > > > > > > 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 <
> > > > > > > [hidden email]>
> > > > > > > > > > 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 <
> > > > > > > > > > [hidden email]
> > > > > > > > > > > >:
> > > > > > > > > > >
> > > > > > > > > > > > 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 <
> > > > > > > > > [hidden email]>
> > > > > > > > > > > > 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 <
> > > > > > > > > > > > > [hidden email]
> > > > > > > > > > > > > >:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > 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 <
> > > > > > > > > > > [hidden email]>
> > > > > > > > > > > > > > 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 <
> > > > > > > > > > > > > > > [hidden email]
> > > > > > > > > > > > > > > >:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Vladimir,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > How does .Net user start caches right now?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Wed, Nov 21, 2018 at 6:10 PM Vladimir
> > Ozerov <
> > > > > > > > > > > > > [hidden email]>
> > > > > > > > > > > > > > > > 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 <
> > > > > > > > > > > > > > > > > [hidden email]
> > > > > > > > > > > > > > > > > >:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 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 <
> > > > > > > > > > > > > > > [hidden email]>
> > > > > > > > > > > > > > > > > > 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 <
> > > > > > > > > > > > > > > > > > > [hidden email]>
> > > > > > > > > > > > > > > > > > > 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 <
> > > > > > > > > > > > > > > > > [hidden email]>
> > > > > > > > > > > > > > > > > > > > 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 <
> > > > > > > > > > > > > > > > > > > > > [hidden email]>
> 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.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

[Vladimir Ozerov]

Ed,

I think most questions around API will go away once we understand how users
are going to use it. Can you provide several examples of properties which
we think are going to be changed often, along with concrete example of API
usage (native API, control.sh, whatever we think important)?

Personally, with my SQL-oriented bias, I do not understand why we call
operation "restart" and why we need API with CacheConfiguration at all. In
SQL world we have ALTER TABLE command which may include one or several
changes for the given table ("cache" in our terms). And in the vast
majority cases user change only one property in a single command. Rarely -
several properties. Extremely rare - redefine the whole table.
Next, not all changes require "restart" at all. In SQL terms we call
operations "ONLINE" when there is no need to stop cache operations for a
long time, and "OFFLINE" otherwise. For Ignite more than half of properties
can be changed "ONLINE" - events flag, write-behind parameters, partition
loss policy, rebalance properties, etc.. I would say that this "change",
not restart.

Thoughts?

On Mon, Nov 26, 2018 at 9:25 PM Eduard Shangareev <
[hidden email]> wrote:

> Ok,
>
> We need two approaches to change cache configuration:
> 1. Ignite.restartCaches(CacheConfiguration ... cfgs);
> 2. Ignite.restartCaches(CacheConfigurationDiff ... cfgDiffs);
>
> Also, we need some versioning of cache configurations for caches. Which
> could be done when we move the cache configuration from serialized file to
> metastore.
>
> It is necessary for several failover scenarios (actually, all of them
> include joining node with outdated configuration).
> And for CAS-like API for restarting caches.
>
>
> On Thu, Nov 22, 2018 at 12:19 PM Vladimir Ozerov <[hidden email]>
> wrote:
>
> > Ed,
> >
> > We have ~70 properties in CacheConfiguration. ~50 of them are plain, ~20
> > are custom classes. My variant allows to change plain properties from any
> > platform, and the rest 20 from any platform when user has relevant
> > BinaryType.
> >
> > On Thu, Nov 22, 2018 at 11:30 AM Eduard Shangareev <
> > [hidden email]> wrote:
> >
> > > I don't see how you variant handles user-defined objects (factories,
> > > affinity-functions, interceptors, etc.). Could you describe?
> > >
> > > On Thu, Nov 22, 2018 at 10:47 AM Vladimir Ozerov <[hidden email]
> >
> > > wrote:
> > >
> > > > My variant of API avoids cache configuration.
> > > >
> > > > One more thing to note - as we found out control.sh cannot dump XML
> > > > configuration. Currently it returns only subset of properties. And in
> > > > general case it is impossible to convert CacheConfiguration to Spring
> > > XML,
> > > > because Spring XMLis not serialization protocol. So API with
> > > > CacheConfiguration doesn’t seem to work for control.sh as well.
> > > >
> > > > чт, 22 нояб. 2018 г. в 10:05, Eduard Shangareev <
> > > > [hidden email]
> > > > >:
> > > >
> > > > > 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 <
> > [hidden email]>
> > > > > 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 <
> > > > > > [hidden email]
> > > > > > >:
> > > > > >
> > > > > > > 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 <
> > > > [hidden email]>
> > > > > > > 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 <
> > > > > > > > [hidden email]> 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 <
> > > > > > [hidden email]>
> > > > > > > > > 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 <
> > > > > > > > > [hidden email]
> > > > > > > > > > >:
> > > > > > > > > >
> > > > > > > > > > > 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 <
> > > > > > > > [hidden email]>
> > > > > > > > > > > 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 <
> > > > > > > > > > > [hidden email]
> > > > > > > > > > > > >:
> > > > > > > > > > > >
> > > > > > > > > > > > > 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 <
> > > > > > > > > > [hidden email]>
> > > > > > > > > > > > > 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 <
> > > > > > > > > > > > > > [hidden email]
> > > > > > > > > > > > > > >:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 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 <
> > > > > > > > > > > > [hidden email]>
> > > > > > > > > > > > > > > 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 <
> > > > > > > > > > > > > > > > [hidden email]
> > > > > > > > > > > > > > > > >:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Vladimir,
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > How does .Net user start caches right now?
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Wed, Nov 21, 2018 at 6:10 PM Vladimir
> > > Ozerov <
> > > > > > > > > > > > > > [hidden email]>
> > > > > > > > > > > > > > > > > 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 <
> > > > > > > > > > > > > > > > > > [hidden email]
> > > > > > > > > > > > > > > > > > >:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 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 <
> > > > > > > > > > > > > > > > [hidden email]>
> > > > > > > > > > > > > > > > > > > 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 <
> > > > > > > > > > > > > > > > > > > > [hidden email]>
> > > > > > > > > > > > > > > > > > > > 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 <
> > > > > > > > > > > > > > > > > > [hidden email]>
> > > > > > > > > > > > > > > > > > > > > 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 <
> > > > > > > > > > > > > > > > > > > > > > [hidden email]>
> > 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.
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>