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