From dev-return-46328-archive-asf-public=cust-asf.ponee.io@ignite.apache.org Tue Jun 18 09:32:30 2019 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 [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id 8E1C518066B for ; Tue, 18 Jun 2019 11:32:30 +0200 (CEST) Received: (qmail 80488 invoked by uid 500); 18 Jun 2019 09:32:29 -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 80476 invoked by uid 99); 18 Jun 2019 09:32:28 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 18 Jun 2019 09:32:28 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id D3EB4C2748 for ; Tue, 18 Jun 2019 09:32:27 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.152 X-Spam-Level: * X-Spam-Status: No, score=1.152 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_REPLY=1, FROM_EXCESS_BASE64=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_HEX=0.1] autolearn=disabled Authentication-Results: spamd1-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id h6BQlu9svD0E for ; Tue, 18 Jun 2019 09:32:25 +0000 (UTC) Received: from mail-ot1-f44.google.com (mail-ot1-f44.google.com [209.85.210.44]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id 0C8DF5F382 for ; Tue, 18 Jun 2019 09:32:25 +0000 (UTC) Received: by mail-ot1-f44.google.com with SMTP id d17so13451354oth.5 for ; Tue, 18 Jun 2019 02:32:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=XV40r2glhcL2C5wRDXmbX1d3MZlYWCrSvXEfIcjOTJs=; b=u7JvmgEv0JbuCWnY6xisvj8USD6Tcr7BrBrSSBDwwE/yh5TMS2/ArixXIoa22uHbmc ZgNqpQ/3MtWXQlWIyq08Uzm2HRj1nmbaRIDlB0k9cdXwgtIhQhRYfxyd8vGYPf9xI0BB NK05tTDCrzSAupswenZlRQSEF5nQYkKt1pfjABJm6ZxcvIMELoer84vVFR0RfICJa0v8 xqsgiNkUCO9BA8TfY9DScoM8NtaT3/htcdtRUU6UZ6lFqD4FreApDIUUFlXOb4YmVPDI iFScFWPJR53v6qwpx3anxp3MWSUDyYRHBSv5U2gCLkn/BPas+hb3Uhx5R4+g1tOdKm3z Q1kg== 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:content-transfer-encoding; bh=XV40r2glhcL2C5wRDXmbX1d3MZlYWCrSvXEfIcjOTJs=; b=m83Wd0Demzs1H1027AMVlUvhIehd0mh4DYhhBQ2ts7XFPAN+wjTwcUUzfSx+mek0WR Xvjn8jx+P+cR3EIi9lAmFwi6PXOHW1f5a4Bl7k7pCh16a2B5N4dBsH9IEDAs9/VBJp+k dwZYUfrCyo/+rDJYRnhhkJ/6SogYknl7r/n11SsNdsrkVAypi92yHDGiK57Rs8XbhIM1 OTvtjsLnuai3OFDfJAnlUGnRupsUpgwJX43/UqR/bUYWMzqOCiNbUXT4hCs/iYpOyg+N m0dwl4aLpFjxEuctCeM+HVnLud6QrJTVtDaOoP+8Ate2ndWyu+x/CVTmTFIxEcMS/qH5 QNTA== X-Gm-Message-State: APjAAAXwsVqWYAU53rp9n4y/wnAECUYCi+T0aBhQ4B3uSLewclTXuxy6 bVu6CRqQo+B7fbmFdot6Cme077JpSJ6qp+8W4yyIDQ== X-Google-Smtp-Source: APXvYqxpMesEom6dN17q2c678kJUZF4LHAV0np/OeGkH4Ru2QIJpmfFj4sCdvbZi2ql1WLWNG2TmwyA/4Dex3RWJGKc= X-Received: by 2002:a9d:392:: with SMTP id f18mr19589261otf.115.1560850342092; Tue, 18 Jun 2019 02:32:22 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?B?0J/QsNCy0LvRg9GF0LjQvSDQmNCy0LDQvQ==?= Date: Tue, 18 Jun 2019 12:32:10 +0300 Message-ID: Subject: Re: [DISCUSSION] Ignite 3.0 and to be removed list To: dev Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Nikolay, Dmitriy, Should we have a separate thread devoted to client nodes? Also, my cent here is from a Hazelcast history. Once they removed their thick client (called LiteMember), but after a while they brought it back. I think we need to learn this lesson in more details. =D0=B2=D1=82, 18 =D0=B8=D1=8E=D0=BD. 2019 =D0=B3. =D0=B2 11:42, Andrey Mash= enkov : > > Also, > * Get rid of old services. > * Make system cache non-persistent or even more - drop it. Discussion on > dev list [1]. > > I have no permissions to edit wiki page and would glad if someone add all > thoughts from this thread. > > [1] > http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-System-c= ache-persistence-td41158.html > > On Tue, Jun 18, 2019 at 10:33 AM Alexey Goncharuk < > alexey.goncharuk@gmail.com> wrote: > > > Folks, > > > > May I ask you to add the mentioned points to the wishlist to keep them = in > > one place for convenience? > > > > =D0=B2=D1=82, 18 =D0=B8=D1=8E=D0=BD. 2019 =D0=B3. =D0=B2 00:19, Alex Pl= ehanov : > > > > > Remove "force server mode" for client nodes (already was discussed on= dev > > > list earlier [1]). > > > > > > [1] : > > > > > > > > http://apache-ignite-developers.2346864.n4.nabble.com/Deprecate-force-s= erver-mode-for-clients-td33614.html > > > > > > =D0=BF=D0=BD, 17 =D0=B8=D1=8E=D0=BD. 2019 =D0=B3. =D0=B2 19:22, Pavel= Tupitsyn : > > > > > > > Big changes for .NET: > > > > * Remove legacy Entity Framework integration > > > > * Remove legacy ASP.NET integration > > > > * Move from .NET Framework 4.0 (released in 2010) to .NET Standard = 2.0 > > > > (modern way to build libraries) > > > > > > > > Thanks, > > > > Pavel > > > > > > > > On Mon, Jun 17, 2019 at 7:14 PM Igor Sapego > > > wrote: > > > > > > > > > For the C++ I propose to drop support of VS 2010 and move to > > > > > at least 2012 (or, better yet 2013). > > > > > > > > > > Also, I'd drop x86 support for everything except for maybe ODBC. > > > > > > > > > > Best Regards, > > > > > Igor > > > > > > > > > > On Mon, Jun 17, 2019 at 7:12 PM Pavel Kovalenko > > > > > wrote: > > > > > > > > > > > I would like to add to the list following: > > > > > > > > > > > > 1. Remove ForceKeyRequests and related code. Since we have Late > > > > affinity > > > > > > assignment and primary node partitions are always up to date we > > don't > > > > > need > > > > > > to request actual data from backups. > > > > > > 2. Remove @CentralizedAffinityFunction and related code. I don'= t > > see > > > > any > > > > > > real usages of custom affinity functions that use this annotati= on. > > > > > > 3. Leave Exchanges Merge + Late Affinity assignment as the only= PME > > > > > > protocol. Remove centralized affinity distribution in case of n= ode > > > left > > > > > and > > > > > > no merge exchange legacy modes. > > > > > > 4. Remove CacheRebalanceMode.NONE and Rebalance Delay as it can > > break > > > > > data > > > > > > consistency in a cluster. Also, remove force rebalance mode as = it > > can > > > > be > > > > > > used only if rebalance delay is set. > > > > > > > > > > > > =D0=BF=D0=BD, 17 =D0=B8=D1=8E=D0=BD. 2019 =D0=B3. =D0=B2 18:39,= Dmitriy Pavlov : > > > > > > > > > > > > > Nikolay, > > > > > > > > > > > > > > we can (and probably should) discuss stop deploying > > caches/services > > > > to > > > > > > > client nodes. > > > > > > > > > > > > > > But I would not name it removal of client nodes at all. Any > > Apache > > > > > Ignite > > > > > > > guide I saw is starting from 2 steps: 1) start server node, 2= ) > > > start > > > > > > client > > > > > > > node. > > > > > > > > > > > > > > There are no reasons to write software if users are unaware o= f > > how > > > to > > > > > use > > > > > > > it. So I do not agree that supplementary materials are > > unimportant. > > > > > > > > > > > > > > Sincerely, > > > > > > > Dmitriy Pavlov > > > > > > > > > > > > > > =D0=BF=D0=BD, 17 =D0=B8=D1=8E=D0=BD. 2019 =D0=B3. =D0=B2 18:3= 0, Nikolay Izhikov < > > nizhikov@apache.org > > > >: > > > > > > > > > > > > > > > Dmitriy, > > > > > > > > > > > > > > > > I think the whole concept of "client" nodes is broken. > > > > > > > > And that's why: > > > > > > > > > > > > > > > > Ignite Client node nothing to do with "client" :) > > > > > > > > We can deploy cache on it, we can execute compute tasks, > > services > > > > on > > > > > > it. > > > > > > > > "client node" is a node with special join process and some > > > > > > rebalance/PME > > > > > > > > hacks. > > > > > > > > And we put many(many!) efforts to support this concept and = this > > > > > hacks. > > > > > > > > > > > > > > > > And I'm asking: What value client nodes bring to Ignite? > > > > > > > > > > > > > > > > I think, Alexey, already answered correctly: > > > > > > > > > > > > > > > > * Transactions support. > > > > > > > > * P2P deployment. > > > > > > > > > > > > > > > > I think we should, definitely, remove concept of "client no= des" > > > in > > > > > the > > > > > > > > future. > > > > > > > > It's about product design decision, in the first place, not > > about > > > > > > > > additional materials. > > > > > > > > > > > > > > > > The simpler core codebase we have, the more reliable produc= t we > > > ca > > > > > > build > > > > > > > > with it. > > > > > > > > > > > > > > > > > > > > > > > > =D0=92 =D0=9F=D0=BD, 17/06/2019 =D0=B2 18:19 +0300, Dmitriy= Pavlov =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > > > > > > > > Hi Nikolay, > > > > > > > > > > > > > > > > > > I think client nodes removal is not possible in the near > > future > > > > > > because > > > > > > > > of > > > > > > > > > tons of usages everywhere outside Ignite code (in product= s, > > > > guides, > > > > > > > > books, > > > > > > > > > training, etc.) > > > > > > > > > > > > > > > > > > If we have replacement we should encourage users to migra= te, > > > but > > > > we > > > > > > > can't > > > > > > > > > remove such a core feature. > > > > > > > > > > > > > > > > > > Alexey, sure we can discuss removal of modules, why not? > > > > > > > > > > > > > > > > > > Sincerely, > > > > > > > > > Dmitriy Pavlov > > > > > > > > > > > > > > > > > > =D0=BF=D0=BD, 17 =D0=B8=D1=8E=D0=BD. 2019 =D0=B3. =D0=B2 = 18:02, Alexey Zinoviev < > > > > > zaleslaw.sin@gmail.com > > > > > > >: > > > > > > > > > > > > > > > > > > > Could we suggest here remove whole modules? > > > > > > > > > > > > > > > > > > > > =D0=BF=D0=BD, 17 =D0=B8=D1=8E=D0=BD. 2019 =D0=B3. =D0= =B2 16:28, Alexey Goncharuk < > > > > > > > > alexey.goncharuk@gmail.com > > > > > > > > > > > : > > > > > > > > > > > Nikolay, > > > > > > > > > > > > > > > > > > > > > > I had this thought too, but I am not too eager to > > implement > > > > it > > > > > > yet. > > > > > > > > The > > > > > > > > > > > reason is transaction protocol complexity/performance > > > issues > > > > > with > > > > > > > > thin > > > > > > > > > > > clients. > > > > > > > > > > > > > > > > > > > > > > A thick client can communicate with each primary node= and > > > > > > > coordinate > > > > > > > > > > > prepare/commit phases. Thin client can only communica= te > > > with > > > > > one > > > > > > > > node, so > > > > > > > > > > > the change will mean an additional network hop. Of > > course, > > > we > > > > > can > > > > > > > > make > > > > > > > > > > > > > > > > > > > > thin > > > > > > > > > > > clients implement the same protocol, but it will > > > immediately > > > > > > > > increase the > > > > > > > > > > > protocol complexity for all platforms. > > > > > > > > > > > > > > > > > > > > > > Plus, we do not have near cache on thin clients, we d= o > > not > > > > > > support > > > > > > > > p2p > > > > > > > > > > > class deployment, etc. Since thin clients are positio= ned > > as > > > > > > > > > > > platform-agnostic, I do not think it makes sense to > > expose > > > > all > > > > > > > > feature > > > > > > > > > > > > > > > > > > > > set > > > > > > > > > > > of Igntie to thin clients. > > > > > > > > > > > > > > > > > > > > > > Instead, we can significantly simplify client node > > > > > configuration > > > > > > - > > > > > > > it > > > > > > > > > > > currently requires the same config as a regular Ignit= e > > > node, > > > > > > > > however, in > > > > > > > > > > > most cases, the configuration can be reduced almost t= o a > > > > > several > > > > > > > > > > > > > > > > > > > > host:port > > > > > > > > > > > pairs. > > > > > > > > > > > > > > > > > > > > > > =D0=BF=D0=BD, 17 =D0=B8=D1=8E=D0=BD. 2019 =D0=B3. =D0= =B2 15:58, Nikolay Izhikov < > > > > > > nizhikov@apache.org > > > > > > > >: > > > > > > > > > > > > > > > > > > > > > > > Alexey. > > > > > > > > > > > > > > > > > > > > > > > > I want to share a thought (just don't drop it out i= n > > one > > > > > moment > > > > > > > :) > > > > > > > > ). > > > > > > > > > > > > > > > > > > > > > > > > Do we really need "client nodes"? > > > > > > > > > > > > > > > > > > > > > > > > We have thin client protocol that is a very conveni= ent > > > > point > > > > > to > > > > > > > > > > > > > > > > > > > > interact > > > > > > > > > > > > with Ignite. > > > > > > > > > > > > So, why, we need one more entity and work mode such= as > > > > > "client > > > > > > > > node"? > > > > > > > > > > > > > > > > > > > > > > > > From my point of view, client nodes were required i= n > > the > > > > time > > > > > > > > without a > > > > > > > > > > > > thin client. > > > > > > > > > > > > Now, we have it. > > > > > > > > > > > > > > > > > > > > > > > > Let's simplify Ignite codebase and drop client node= s! > > > > > > > > > > > > > > > > > > > > > > > > How does it sound? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =D0=92 =D0=9F=D0=BD, 17/06/2019 =D0=B2 15:52 +0300,= Alexey Goncharuk =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > > > > > > > > > > > > Nikolay, > > > > > > > > > > > > > > > > > > > > > > > > > > Local caches and scalar are already in the list := ) > > > Added > > > > > the > > > > > > > > outdated > > > > > > > > > > > > > metrics point. > > > > > > > > > > > > > > > > > > > > > > > > > > =D0=BF=D0=BD, 17 =D0=B8=D1=8E=D0=BD. 2019 =D0=B3.= =D0=B2 15:32, Nikolay Izhikov < > > > > > > > > nizhikov@apache.org>: > > > > > > > > > > > > > > > > > > > > > > > > > > > * Scalar. > > > > > > > > > > > > > > * LOCAL caches. > > > > > > > > > > > > > > * Deprecated metrics. > > > > > > > > > > > > > > > > > > > > > > > > > > > > =D0=92 =D0=9F=D0=BD, 17/06/2019 =D0=B2 15:18 +0= 300, Alexey Goncharuk > > > =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > > > > > > > > > > > > > > Igniters, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Even though we are still planning the Ignite = 2.8 > > > > > > release, I > > > > > > > > would > > > > > > > > > > > > > > > > > > > > > > > > like to > > > > > > > > > > > > > > > kick-off a discussion related to Ignite 3.0, > > > because > > > > > the > > > > > > > > efforts > > > > > > > > > > > > > > > > > > > > > > for > > > > > > > > > > > > AI > > > > > > > > > > > > > > > > > > > > > > > > > > > > 3.0 > > > > > > > > > > > > > > > will be significantly larger than for AI 2.8, > > > better > > > > to > > > > > > > start > > > > > > > > > > > > > > > > > > > > > > early. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > As a first step, I would like to discuss the = list > > > of > > > > > > things > > > > > > > > to be > > > > > > > > > > > > > > > > > > > > > > > > removed > > > > > > > > > > > > > > > in Ignite 3.0 (partially this thread is inspi= red > > by > > > > > Denis > > > > > > > > Magda's > > > > > > > > > > > > > > > > > > > > > > > > IGFS > > > > > > > > > > > > > > > removal thread). I've separated all to-be-rem= oved > > > > > points > > > > > > > from > > > > > > > > > > > > > > > > > > > > > > > > existing > > > > > > > > > > > > > > > Ignite 3.0 wishlist [1] to a dedicated block = and > > > also > > > > > > added > > > > > > > > a few > > > > > > > > > > > > > > > > > > > > > > > > more > > > > > > > > > > > > > > > things that look right to be dropped. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Please share your thoughts, probably, there a= re > > > more > > > > > > > outdated > > > > > > > > > > > > > > > > > > > > > > things > > > > > > > > > > > > we > > > > > > > > > > > > > > > need to add to the wishlist. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > As a side question: I think it makes sense to > > > create > > > > > > > tickets > > > > > > > > for > > > > > > > > > > > > > > > > > > > > > > such > > > > > > > > > > > > > > > improvements, how do we track them. Will the = 3.0 > > > > > version > > > > > > > > suffice > > > > > > > > > > > > > > > > > > > > or > > > > > > > > > > > > > > > > > > > > > > > > > > > > should > > > > > > > > > > > > > > > we add a separate label? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > Best regards, > Andrey V. Mashenkov --=20 Best regards, Ivan Pavlukhin