From dev-return-42229-archive-asf-public=cust-asf.ponee.io@ignite.apache.org Wed Nov 21 16:22:59 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id C72DF180668 for ; Wed, 21 Nov 2018 16:22:58 +0100 (CET) Received: (qmail 95850 invoked by uid 500); 21 Nov 2018 15:22:57 -0000 Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@ignite.apache.org Delivered-To: mailing list dev@ignite.apache.org Received: (qmail 95832 invoked by uid 99); 21 Nov 2018 15:22:57 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 21 Nov 2018 15:22:57 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id C1DAA18BE92 for ; Wed, 21 Nov 2018 15:22:56 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 0.54 X-Spam-Level: X-Spam-Status: No, score=0.54 tagged_above=-999 required=6.31 tests=[DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd3-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gridgain-com.20150623.gappssmtp.com Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id tgHq0oZL2CBL for ; Wed, 21 Nov 2018 15:22:54 +0000 (UTC) Received: from mail-vs1-f46.google.com (mail-vs1-f46.google.com [209.85.217.46]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id F2EA7621E9 for ; Wed, 21 Nov 2018 15:22:53 +0000 (UTC) Received: by mail-vs1-f46.google.com with SMTP id x64so3469334vsa.5 for ; Wed, 21 Nov 2018 07:22:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gridgain-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=h6eoDrfAQA2xbw2TfV5ema4ulNX2u6IiFsKzqA4//78=; b=No0RTxzWqfyGpzW5fQW2J1WovZwQ08zCHbDsltN6Islp3PRV9FQfrsj9G11wLDrxUf BTzlGcqCua0o6nbOxG//JCjLoFtdobbhAH5XIL/P4KX8T8ke63Qr0Psi2y1eufK3EjUo mwu3Ivc16KctK79GqpPsfDzae4ojVwjFMx3rfqPQ5f3C9wVFEUf3qlzUB+W1Li4bE/Fl oKrwQqRPtpaH1XkyiL5m761rKj/fPgR95xtXyzZEU7ebIUFge48hIUUjxUnAsgjyTdmF h74ztMFotvgmWVg/SXQmihVaMBwUBc+iZPT3Zgm2paXvw7reEeF9FB+lRG8uqcSfvz0n QUmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=h6eoDrfAQA2xbw2TfV5ema4ulNX2u6IiFsKzqA4//78=; b=tTPGZ83tBkf7iDLEj3fL6dBiOq7mYh7eNnT5BJ2+emuffnzICL/GLP8q/ySuXkAffq DenQH8Gy34gNOjm+Ha8oVTvVNIqaKB4e9e1mRiO0o1FEdeWb3ZHWvH5NWanWQIhROPdI J+umRar+ouPt8qBqAphHJr5zjaC5ZLEitEchgP7yUUxh/aPKMp1gQcQRPI0n3Vq79MW4 UYx9/+A+4XaIVr5PD5jJdzqT461e/sq66mjmD5GqUd2KqHxacesREd5XDjh0/FSQagqc eovrE6UBN/QnVSU4YbA+1mAzc62Xefy/5wT2Jr7rJrrI1jt077Z7FtMJ9zWjJ+L9bRrJ UY/A== X-Gm-Message-State: AGRZ1gKxeVmTVMy5hlc8orqgFfal9HODGRb6g3QYuwZAP4ShfM6k0ySx HYrG7Hk5/OXkTiPsARL26R0Y7qPdFHnyRr74/VZtDhiiXMk= X-Google-Smtp-Source: AJdET5fzUc5/8qrufOZ2t3jM3GxnneppXxA3qDMF/IZucK/+mvf7v/keOai8TSJqDnMvpznoAU7JDKs964REPkr9GGw= X-Received: by 2002:a67:1346:: with SMTP id 67mr2613476vst.31.1542813766791; Wed, 21 Nov 2018 07:22:46 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Vladimir Ozerov Date: Wed, 21 Nov 2018 18:22:36 +0300 Message-ID: Subject: Re: New API for changing configuration of persistent caches To: dev@ignite.apache.org Content-Type: multipart/alternative; boundary="000000000000864b37057b2e52ea" --000000000000864b37057b2e52ea Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Alex, Spring XML is not easily available from API. Sometimes it simply doesn=E2= =80=99t exist. Why not use builder instead? Ignite.changeCache(=E2=80=9Cmy_cache=E2=80=9D, Builder.create().setCacheMode(REPLICATED).build()) Advantages: 1) Available on all platforms 2) Expose only properties we support 3) Avoid race condition when configuration changes between configuration read and method call (what could lead to a number of strange effects). Makes sense? =D1=81=D1=80, 21 =D0=BD=D0=BE=D1=8F=D0=B1. 2018 =D0=B3. =D0=B2 18:16, Alexe= y Kuznetsov : > Vova, Ed > > I think in case when classes not available we can sent a string with cach= e > XML configuration (bean) to server node that has all classes in classpath= . > > What do you think? > > On Wed, Nov 21, 2018 at 10:10 PM Vladimir Ozerov > wrote: > > > Eduard, > > > > Simple !=3D correct. Let=E2=80=99s consider a simple use case: user wan= t to change > > PARTITIONED -> REPLICATED from .NET, but do not some classes from > > CacheConfiguration. How do we solve this? > > > > Vladimir. > > > > =D1=81=D1=80, 21 =D0=BD=D0=BE=D1=8F=D0=B1. 2018 =D0=B3. =D0=B2 18:02, E= duard 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 > > > wrote: > > > > > > > Eduard, > > > > > > > > Got it. Please take the following things in count during design: > > > > > > > > 1) Two distinct PMEs might not work well. Consider a situation w1he= n > I > > > > decided to move a cache with index "MY_INDEX" from schema A to sche= ma > > 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 hav= e > 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. "detai= l > > > > 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 applie= d. > > 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 thin= gs > > > 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 =3D ...; > > > > > > > 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 the= m. > > > > > > > > > > > > > > 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=3Dfalse; > > > > > > > - 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. > > > > > > > > > > > > > > > > > -- > Alexey Kuznetsov > --000000000000864b37057b2e52ea--