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 Thu, 22 Nov 2018 05:50:10 GMT
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