ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eduard Shangareev <eduard.shangar...@gmail.com>
Subject Re: New API for changing configuration of persistent caches
Date Mon, 26 Nov 2018 18:24:51 GMT
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 <vozerov@gridgain.com>
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 <
> eduard.shangareev@gmail.com> 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 <vozerov@gridgain.com>
> > 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 <
> > > eduard.shangareev@gmail.com
> > > >:
> > >
> > > > 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 <
> vozerov@gridgain.com>
> > > > wrote:
> > > >
> > > > > Ed,
> > > > >
> > > > > We may have API similar to “cache” and “getOrCreateCache”, or may
> > not.
> > > It
> > > > > is up to us to decide. Similarity on it’s own is weak argument.
> > > > > Functionality and simplicity - this is what matters.
> > > > >
> > > > > Approach with cache configuration has three major issues
> > > > > 1) It exposes properties which user will not be able to change, so
> > > > typical
> > > > > user actions would be: try to change property, fail as it is
> > > unsupported,
> > > > > go reading documentation. Approach with separate POJO is intuitive
> > and
> > > > > self-documenting.
> > > > > 2) It has race condition between config read and config apply, so
> > user
> > > do
> > > > > not know what exactly he changes, unless you change API to
> something
> > > like
> > > > > “restartCaches(Tuple<CacheConfiguration, CacheConfiguration>...)”,
> > > which
> > > > > user will need to call in a loop.
> > > > > 3) And it is not suitable for non-Java platform, which is a
> > > showstopper -
> > > > > all API should be available from all platforms unless it is proven
> to
> > > be
> > > > > impossible to implement.
> > > > >
> > > > > Vladimir.
> > > > >
> > > > > чт, 22 нояб. 2018 г. в 1:06, Eduard Shangareev <
> > > > > eduard.shangareev@gmail.com
> > > > > >:
> > > > >
> > > > > > Vovan,
> > > > > >
> > > > > > Would you argue that we should have the similar API in Java as
> > > > > > Ignite.cache(CacheConfiguration) or
> > > > > > Ignite.getOrCreateCache(CacheConfiguration)?
> > > > > >
> > > > > > With a proposed solution, every other API call would rely on it
> > > > finally.
> > > > > >
> > > > > > I am interested in having such feature not arguing about API
> > > > > alternatives.
> > > > > >
> > > > > > We definitely should have the ability to change it via control.sh
> > and
> > > > > Java
> > > > > > API. Everything else is optional from my point of view (at least
> on
> > > the
> > > > > > current stage).
> > > > > >
> > > > > > Moreover, your arguments are more about our format of
> > > > CacheConfiguration
> > > > > > which couldn't be defined in other languages and clients. So,
> maybe
> > > we
> > > > > > should start a discussion about how we should change it in 3.0?
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Wed, Nov 21, 2018 at 7:45 PM Vladimir Ozerov <
> > > vozerov@gridgain.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Ed,
> > > > > > >
> > > > > > > Why do we want to operate on CacheConfiguration so desperately?
> > > Your
> > > > > > > example raises even more questions:
> > > > > > > 1) What to do with thin clients?
> > > > > > > 2) What to do with aforementioned race conditions, when cache
> > could
> > > > be
> > > > > > > changed concurrently?
> > > > > > > 3) Why such trivial operation from user perspective is only
> > > supported
> > > > > > from
> > > > > > > control.sh and not from the rest API (even Java client nodes
> will
> > > be
> > > > > > > affected - remember our plans to remove requirement to have
> cache
> > > > > classes
> > > > > > > on client nodes, which is yet to be implemented).
> > > > > > >
> > > > > > > Compare it to alternative API:
> > > > > > >
> > > > > > > 1) Native call from any language without limitations:
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> Ignite.changeCache(CacheConfigurationChange.create().setCacheMode(REPLICATED).setBackups(2));
> > > > > > >
> > > > > > > 2) Call from control.sh in one line without race conditions
> with
> > > > > > concurrent
> > > > > > > cache changes:
> > > > > > > control.sh --cache --change cacheMode=REPLICATED backups=2
> > > > > > >
> > > > > > > On Wed, Nov 21, 2018 at 7:32 PM Eduard Shangareev <
> > > > > > > eduard.shangareev@gmail.com> wrote:
> > > > > > >
> > > > > > > > Vovan,
> > > > > > > >
> > > > > > > > user already is able to get cache configuration as xml.
> > > > > > > > control.sh --cache list '.' --config
> > > > > > > >
> > > > > > > > So, user could update it and run:
> > > > > > > > control.sh --cache --restart -cfg=xml.path
> > > > > > > >
> > > > > > > >
> > > > > > > > On Wed, Nov 21, 2018 at 7:06 PM Vladimir Ozerov <
> > > > > vozerov@gridgain.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Ed,
> > > > > > > > >
> > > > > > > > > He can do that programmatically. But I meant another case -
> > > Java
> > > > > node
> > > > > > > > > creates a cache. Then .NET node wants to change it.
> Proposed
> > > API
> > > > > > cannot
> > > > > > > > > handle it.
> > > > > > > > >
> > > > > > > > > ср, 21 нояб. 2018 г. в 19:03, Eduard Shangareev <
> > > > > > > > eshangareev@gridgain.com
> > > > > > > > > >:
> > > > > > > > >
> > > > > > > > > > Vladimir,
> > > > > > > > > >
> > > > > > > > > > I didn't get how does .Net user start caches right now?
> XML
> > > and
> > > > > > > remote
> > > > > > > > > > node? Right?
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Wed, Nov 21, 2018 at 6:55 PM Vladimir Ozerov <
> > > > > > > vozerov@gridgain.com>
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Ed,
> > > > > > > > > > >
> > > > > > > > > > > We are not Java product. We support 6 platforms at the
> > > > moment.
> > > > > > Why
> > > > > > > do
> > > > > > > > > we
> > > > > > > > > > > implement a feature which can only be used in Java,
> when
> > it
> > > > is
> > > > > > very
> > > > > > > > > easy
> > > > > > > > > > to
> > > > > > > > > > > make it available from everywhere?
> > > > > > > > > > >
> > > > > > > > > > > ср, 21 нояб. 2018 г. в 18:50, Eduard Shangareev <
> > > > > > > > > > eshangareev@gridgain.com
> > > > > > > > > > > >:
> > > > > > > > > > >
> > > > > > > > > > > > Vladimir,
> > > > > > > > > > > >
> > > > > > > > > > > > It would be Java API specific.
> > > > > > > > > > > > For a user, we would add a new command for console.sh
> > > which
> > > > > > would
> > > > > > > > > take
> > > > > > > > > > an
> > > > > > > > > > > > XML-file path as a parameter.
> > > > > > > > > > > >
> > > > > > > > > > > > We could add other possibilities: for example, with
> the
> > > > > builder
> > > > > > > > which
> > > > > > > > > > > would
> > > > > > > > > > > > finally call this Ignite.restartCaches method. But
> it's
> > > > nice
> > > > > to
> > > > > > > > have,
> > > > > > > > > > > not a
> > > > > > > > > > > > mandatory one.
> > > > > > > > > > > >
> > > > > > > > > > > > On Wed, Nov 21, 2018 at 6:43 PM Vladimir Ozerov <
> > > > > > > > > vozerov@gridgain.com>
> > > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > Ed,
> > > > > > > > > > > > >
> > > > > > > > > > > > > Could you please demonstrate how .NET node or .NET
> > will
> > > > > > change
> > > > > > > > > cache
> > > > > > > > > > > > > configuration with proposed API? Taking in count
> that
> > > XML
> > > > > is
> > > > > > > not
> > > > > > > > > > > > available
> > > > > > > > > > > > > in most cases, and custom Java classes from cache
> > > > > > configuration
> > > > > > > > are
> > > > > > > > > > > > > available only on server nodes and only from Java.
> > > > > > > > > > > > >
> > > > > > > > > > > > > ср, 21 нояб. 2018 г. в 18:36, Eduard Shangareev <
> > > > > > > > > > > > > eduard.shangareev@gmail.com
> > > > > > > > > > > > > >:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Vladimir,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I don't see any difference here.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > The same possibilities would be available as with
> > > > normal
> > > > > > > cache
> > > > > > > > > > start:
> > > > > > > > > > > > > > -XML;
> > > > > > > > > > > > > > -remote node.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > >3) Avoid race condition when configuration
> changes
> > > > > between
> > > > > > > > > > > > configuration
> > > > > > > > > > > > > > read and method call (what could lead to a number
> > of
> > > > > > strange
> > > > > > > > > > > effects).
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Well, we could add *old* configuration parameter
> > for
> > > > > > CAS-like
> > > > > > > > > > > semantic.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Wed, Nov 21, 2018 at 6:26 PM Vladimir Ozerov <
> > > > > > > > > > > vozerov@gridgain.com>
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Ed,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Caches in .NET could be started
> programmatically,
> > > > from
> > > > > > XML
> > > > > > > > > which
> > > > > > > > > > > .NET
> > > > > > > > > > > > > API
> > > > > > > > > > > > > > > has no access to, or dynamically from remote
> > nodes
> > > > (eg
> > > > > > Java
> > > > > > > > > > node).
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > ср, 21 нояб. 2018 г. в 18:24, Eduard
> Shangareev <
> > > > > > > > > > > > > > > eduard.shangareev@gmail.com
> > > > > > > > > > > > > > > >:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Vladimir,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > How does .Net user start caches right now?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Wed, Nov 21, 2018 at 6:10 PM Vladimir
> > Ozerov <
> > > > > > > > > > > > > vozerov@gridgain.com>
> > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Eduard,
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Simple != correct. Let’s consider a simple
> > use
> > > > > case:
> > > > > > > user
> > > > > > > > > > want
> > > > > > > > > > > to
> > > > > > > > > > > > > > > change
> > > > > > > > > > > > > > > > > PARTITIONED -> REPLICATED from .NET, but do
> > not
> > > > > some
> > > > > > > > > classes
> > > > > > > > > > > from
> > > > > > > > > > > > > > > > > CacheConfiguration. How do we solve this?
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Vladimir.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > ср, 21 нояб. 2018 г. в 18:02, Eduard
> > > Shangareev <
> > > > > > > > > > > > > > > > > eduard.shangareev@gmail.com
> > > > > > > > > > > > > > > > > >:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Vladimir,
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > I propose not to change cache
> configuration
> > > in
> > > > > > > runtime
> > > > > > > > > but
> > > > > > > > > > > > > restart
> > > > > > > > > > > > > > > > cache
> > > > > > > > > > > > > > > > > > with the new compatible configuration on
> > data
> > > > > which
> > > > > > > we
> > > > > > > > > have
> > > > > > > > > > > > > > > underfoot.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > What we could change:
> > > > > > > > > > > > > > > > > > -backup count;
> > > > > > > > > > > > > > > > > > -TRANSACTIONAL <-> ATOMIC;
> > > > > > > > > > > > > > > > > > -REPLICATED - PARTITIONED;
> > > > > > > > > > > > > > > > > > -other settings.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > So, yeah, it would be great to have a
> > > > possibility
> > > > > > to
> > > > > > > > > change
> > > > > > > > > > > > some
> > > > > > > > > > > > > > > > > properties
> > > > > > > > > > > > > > > > > > in runtime. But right we don't any way to
> > > > change
> > > > > > > > anything
> > > > > > > > > > > > except
> > > > > > > > > > > > > > > > indexes
> > > > > > > > > > > > > > > > > > and SQL fields.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > We already have all mechanism to do this.
> > > > > > > > > > > > > > > > > > The main issue is to make it reliable and
> > > > exclude
> > > > > > > cases
> > > > > > > > > > when
> > > > > > > > > > > we
> > > > > > > > > > > > > > could
> > > > > > > > > > > > > > > > > come
> > > > > > > > > > > > > > > > > > to the unrecoverable state.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > So, I suggest keeping the solution as
> > simple
> > > as
> > > > > > > > possible.
> > > > > > > > > > > > > > > > > > For indexes clashes and
> > > ClassNotFoundException
> > > > we
> > > > > > > could
> > > > > > > > > > > revert
> > > > > > > > > > > > > > > > > > configuration update and start with the
> old
> > > > > > > > > configuration.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Wed, Nov 21, 2018 at 5:44 PM Vladimir
> > > > Ozerov <
> > > > > > > > > > > > > > > vozerov@gridgain.com>
> > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Eduard,
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Got it. Please take the following
> things
> > in
> > > > > count
> > > > > > > > > during
> > > > > > > > > > > > > design:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 1) Two distinct PMEs might not work
> well.
> > > > > > Consider
> > > > > > > a
> > > > > > > > > > > > situation
> > > > > > > > > > > > > > > w1hen
> > > > > > > > > > > > > > > > I
> > > > > > > > > > > > > > > > > > > decided to move a cache with index
> > > "MY_INDEX"
> > > > > > from
> > > > > > > > > > schema A
> > > > > > > > > > > > to
> > > > > > > > > > > > > > > schema
> > > > > > > > > > > > > > > > > B.
> > > > > > > > > > > > > > > > > > > While cache was stopped, another cache
> > with
> > > > > index
> > > > > > > > > > > "MY_INDEX"
> > > > > > > > > > > > > was
> > > > > > > > > > > > > > > > > created
> > > > > > > > > > > > > > > > > > in
> > > > > > > > > > > > > > > > > > > schema B. Now first cache cannot start
> > due
> > > to
> > > > > > index
> > > > > > > > > name
> > > > > > > > > > > > > > conflict.
> > > > > > > > > > > > > > > > > > > 2) Cancelling index creation is also
> bad
> > > idea
> > > > > > > because
> > > > > > > > > > this
> > > > > > > > > > > is
> > > > > > > > > > > > > > > > > potentially
> > > > > > > > > > > > > > > > > > > long operation. Instead, most likely
> that
> > > we
> > > > > > should
> > > > > > > > > wait
> > > > > > > > > > to
> > > > > > > > > > > > > > > > concurrent
> > > > > > > > > > > > > > > > > > > schema operations to finish first. That
> > is,
> > > > all
> > > > > > > > > > operations
> > > > > > > > > > > on
> > > > > > > > > > > > > > cache
> > > > > > > > > > > > > > > > > > should
> > > > > > > > > > > > > > > > > > > be ordered wrt each other somehow
> > > > > > > > > > > > > > > > > > > 3) Why do we think that cache restart
> > will
> > > be
> > > > > > > needed
> > > > > > > > at
> > > > > > > > > > > all?
> > > > > > > > > > > > We
> > > > > > > > > > > > > > > have
> > > > > > > > > > > > > > > > a
> > > > > > > > > > > > > > > > > > lot
> > > > > > > > > > > > > > > > > > > of configuration properties which could
> > be
> > > > > > changed
> > > > > > > > > safely
> > > > > > > > > > > > > either
> > > > > > > > > > > > > > > > > without
> > > > > > > > > > > > > > > > > > > PME or with a single PME. - rebalance
> > > > > properties,
> > > > > > > > cache
> > > > > > > > > > > store
> > > > > > > > > > > > > > > > > properties
> > > > > > > > > > > > > > > > > > > (especially write-behind stuff), some
> > query
> > > > > > > > properties
> > > > > > > > > > > (e.g.
> > > > > > > > > > > > > > > "detail
> > > > > > > > > > > > > > > > > > > metrics"), etc.. In essence, it seems
> > that
> > > > >50%
> > > > > > of
> > > > > > > > > > > properties
> > > > > > > > > > > > > > could
> > > > > > > > > > > > > > > > be
> > > > > > > > > > > > > > > > > > > changed without cache restart, other
> 25%
> > > will
> > > > > not
> > > > > > > be
> > > > > > > > > > > > supported,
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > rest may require restart.
> > > > > > > > > > > > > > > > > > > 4) Client nodes and thin client may not
> > > have
> > > > > > > > necessary
> > > > > > > > > > > > classes
> > > > > > > > > > > > > in
> > > > > > > > > > > > > > > > > > > classpath. E.g. consider a user which
> > want
> > > to
> > > > > > > change
> > > > > > > > > > > > rebalance
> > > > > > > > > > > > > > > > timeout
> > > > > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > > > cache, but do not have configured
> > > interceptor
> > > > > in
> > > > > > > > > > classpath.
> > > > > > > > > > > > > With
> > > > > > > > > > > > > > > > > proposed
> > > > > > > > > > > > > > > > > > > API it will be impossible. This is
> > > especially
> > > > > > true
> > > > > > > > for
> > > > > > > > > > > > non-Java
> > > > > > > > > > > > > > > > > clients.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > That said, I think we should consider
> > > another
> > > > > API
> > > > > > > > which
> > > > > > > > > > > will
> > > > > > > > > > > > > not
> > > > > > > > > > > > > > > > > require
> > > > > > > > > > > > > > > > > > > full CacheConfiguration object. This
> > might
> > > > be a
> > > > > > > kind
> > > > > > > > of
> > > > > > > > > > > > builder
> > > > > > > > > > > > > > or
> > > > > > > > > > > > > > > > so.
> > > > > > > > > > > > > > > > > > And
> > > > > > > > > > > > > > > > > > > once user set properties he want to
> > change
> > > to
> > > > > the
> > > > > > > > > > builder,
> > > > > > > > > > > we
> > > > > > > > > > > > > can
> > > > > > > > > > > > > > > > > analyze
> > > > > > > > > > > > > > > > > > > them and either change them in runtime
> > > > without
> > > > > > PME,
> > > > > > > > > > change
> > > > > > > > > > > > > with a
> > > > > > > > > > > > > > > > > single
> > > > > > > > > > > > > > > > > > > PME or change with full cache restart.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > What do you think?
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Vladimir.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > On Wed, Nov 21, 2018 at 5:01 PM Eduard
> > > > > > Shangareev <
> > > > > > > > > > > > > > > > > > > eshangareev@gridgain.com>
> > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Vladimir,
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > 1) Affinity could be changed, but
> count
> > > of
> > > > > > > > partition
> > > > > > > > > > > > couldn't
> > > > > > > > > > > > > > be.
> > > > > > > > > > > > > > > > > > > > 2) So it would trigger 2 PME. Dynamic
> > > start
> > > > > and
> > > > > > > > stop.
> > > > > > > > > > > > > > > > > > > > 3) In theory, should cancel them and
> > new
> > > > > > setting
> > > > > > > > > should
> > > > > > > > > > > be
> > > > > > > > > > > > > > > applied.
> > > > > > > > > > > > > > > > > How
> > > > > > > > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > > > > > works now? Create an index and stop
> > node,
> > > > for
> > > > > > > > > example.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > On Wed, Nov 21, 2018 at 4:56 PM
> > Vladimir
> > > > > > Ozerov <
> > > > > > > > > > > > > > > > > vozerov@gridgain.com>
> > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Hi Ed,
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Several questions from my side:
> > > > > > > > > > > > > > > > > > > > > 1) If we do not allow to change the
> > > most
> > > > > > > demanded
> > > > > > > > > by
> > > > > > > > > > > > users
> > > > > > > > > > > > > > > things
> > > > > > > > > > > > > > > > > > like
> > > > > > > > > > > > > > > > > > > > > affinity or persistence/in-memory,
> > then
> > > > > what
> > > > > > > kind
> > > > > > > > > of
> > > > > > > > > > > > > > > > configuration
> > > > > > > > > > > > > > > > > > > > > properties do we expect to be
> > changed?
> > > > Can
> > > > > we
> > > > > > > > have
> > > > > > > > > > > > several
> > > > > > > > > > > > > > > > > examples?
> > > > > > > > > > > > > > > > > > > > > 2) How will it interact with PME?
> > > > > > > > > > > > > > > > > > > > > 3) How will it interact with CREATE
> > > INDEX
> > > > > and
> > > > > > > > ALTER
> > > > > > > > > > > TABLE
> > > > > > > > > > > > > > > > commands?
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > On Wed, Nov 21, 2018 at 4:48 PM
> > Eduard
> > > > > > > > Shangareev <
> > > > > > > > > > > > > > > > > > > > > eduard.shangareev@gmail.com>
> wrote:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Igniters,
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > I propose new public API to
> change
> > > the
> > > > > > cache
> > > > > > > > > > > > > configuration
> > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > > > persistent
> > > > > > > > > > > > > > > > > > > > > > caches with keeping data.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > It would look like:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Ignite ignite = ...;
> > > > > > > > > > > > > > > > > > > > > > ignite.restartCaches(cfg1, ...
> > cfgN);
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > where cfgX is a new cache
> > > > configuration,
> > > > > > > which
> > > > > > > > > > > contains
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > name
> > > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > > an
> > > > > > > > > > > > > > > > > > > > > > existing persistent cache.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > The obvious limitation:
> > > > > > > > > > > > > > > > > > > > > > - affinity key mapping couldn't
> be
> > > > > changed;
> > > > > > > > > > > > > > > > > > > > > > - count of partitions couldn't be
> > > > > changed;
> > > > > > > > > > > > > > > > > > > > > > - MVCC couldn't be turned off/on;
> > > > > > > > > > > > > > > > > > > > > > - persistent couldn't be turned
> > off;
> > > > > > > > > > > > > > > > > > > > > > - group settings couldn't be
> > changed
> > > > > (group
> > > > > > > > > name);
> > > > > > > > > > > > > > > > > > > > > > - if cache belongs to group it's
> > > needed
> > > > > to
> > > > > > > > > restart
> > > > > > > > > > > all
> > > > > > > > > > > > of
> > > > > > > > > > > > > > > them.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Failure scenario is the crucial
> > thing
> > > > > (and
> > > > > > > most
> > > > > > > > > > > > > difficult):
> > > > > > > > > > > > > > > > > > > > > > - initiator fail;
> > > > > > > > > > > > > > > > > > > > > > - cluster restart at any stage;
> > > > > > > > > > > > > > > > > > > > > > - joining/starting offline nodes.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Some thoughts about
> implementation:
> > > > > > > > > > > > > > > > > > > > > > - stop cache with destroy=false;
> > > > > > > > > > > > > > > > > > > > > > - start cache dynamically with
> new
> > > > > > > > configuration;
> > > > > > > > > > > > > > > > > > > > > > - if indexes settings changed -
> > > remove
> > > > > > > > index.bin
> > > > > > > > > to
> > > > > > > > > > > > start
> > > > > > > > > > > > > > > > > > indexation;
> > > > > > > > > > > > > > > > > > > > > > - change blt-history when start
> > cache
> > > > > > > initiated
> > > > > > > > > to
> > > > > > > > > > > not
> > > > > > > > > > > > > > allow
> > > > > > > > > > > > > > > > join
> > > > > > > > > > > > > > > > > > > nodes
> > > > > > > > > > > > > > > > > > > > > > with old configuration;
> > > > > > > > > > > > > > > > > > > > > > - use restartId (IGNITE-8911) to
> > not
> > > > > allow
> > > > > > to
> > > > > > > > > start
> > > > > > > > > > > > cache
> > > > > > > > > > > > > > in
> > > > > > > > > > > > > > > > > > between.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Your thoughts? Would it be a
> useful
> > > > > > feature?
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > > > > > > Best regards,
> > > > > > > > > > > > > > > > > > > > Eduard.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > --
> > > > > > > > > > > > Best regards,
> > > > > > > > > > > > Eduard.
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Best regards,
> > > > > > > > > > Eduard.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message