ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Ozerov <voze...@gridgain.com>
Subject Re: New API for changing configuration of persistent caches
Date Wed, 21 Nov 2018 16:45:20 GMT
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