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-cache-persistence-td41158.html On Tue, Jun 18, 2019 at 10:33 AM Alexey Goncharuk < alexey.goncha...@gmail.com> wrote: > Folks, > > May I ask you to add the mentioned points to the wishlist to keep them in > one place for convenience? > > вт, 18 июн. 2019 г. в 00:19, Alex Plehanov <plehanov.a...@gmail.com>: > > > 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-server-mode-for-clients-td33614.html > > > > пн, 17 июн. 2019 г. в 19:22, Pavel Tupitsyn <ptupit...@apache.org>: > > > > > 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 <isap...@gridgain.com> > > 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 <jokse...@gmail.com> > > > > 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 annotation. > > > > > 3. Leave Exchanges Merge + Late Affinity assignment as the only PME > > > > > protocol. Remove centralized affinity distribution in case of node > > 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. > > > > > > > > > > пн, 17 июн. 2019 г. в 18:39, Dmitriy Pavlov <dpav...@apache.org>: > > > > > > > > > > > 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 of > how > > to > > > > use > > > > > > it. So I do not agree that supplementary materials are > unimportant. > > > > > > > > > > > > Sincerely, > > > > > > Dmitriy Pavlov > > > > > > > > > > > > пн, 17 июн. 2019 г. в 18:30, Nikolay Izhikov < > nizhi...@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 nodes" > > 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 product we > > ca > > > > > build > > > > > > > with it. > > > > > > > > > > > > > > > > > > > > > В Пн, 17/06/2019 в 18:19 +0300, Dmitriy Pavlov пишет: > > > > > > > > Hi Nikolay, > > > > > > > > > > > > > > > > I think client nodes removal is not possible in the near > future > > > > > because > > > > > > > of > > > > > > > > tons of usages everywhere outside Ignite code (in products, > > > guides, > > > > > > > books, > > > > > > > > training, etc.) > > > > > > > > > > > > > > > > If we have replacement we should encourage users to migrate, > > but > > > we > > > > > > can't > > > > > > > > remove such a core feature. > > > > > > > > > > > > > > > > Alexey, sure we can discuss removal of modules, why not? > > > > > > > > > > > > > > > > Sincerely, > > > > > > > > Dmitriy Pavlov > > > > > > > > > > > > > > > > пн, 17 июн. 2019 г. в 18:02, Alexey Zinoviev < > > > > zaleslaw....@gmail.com > > > > > >: > > > > > > > > > > > > > > > > > Could we suggest here remove whole modules? > > > > > > > > > > > > > > > > > > пн, 17 июн. 2019 г. в 16:28, Alexey Goncharuk < > > > > > > > alexey.goncha...@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 communicate > > 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 do > not > > > > > support > > > > > > > p2p > > > > > > > > > > class deployment, etc. Since thin clients are positioned > 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 Ignite > > node, > > > > > > > however, in > > > > > > > > > > most cases, the configuration can be reduced almost to a > > > > several > > > > > > > > > > > > > > > > > > host:port > > > > > > > > > > pairs. > > > > > > > > > > > > > > > > > > > > пн, 17 июн. 2019 г. в 15:58, Nikolay Izhikov < > > > > > nizhi...@apache.org > > > > > > >: > > > > > > > > > > > > > > > > > > > > > Alexey. > > > > > > > > > > > > > > > > > > > > > > I want to share a thought (just don't drop it out in > one > > > > moment > > > > > > :) > > > > > > > ). > > > > > > > > > > > > > > > > > > > > > > Do we really need "client nodes"? > > > > > > > > > > > > > > > > > > > > > > We have thin client protocol that is a very convenient > > > 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 in > the > > > time > > > > > > > without a > > > > > > > > > > > thin client. > > > > > > > > > > > Now, we have it. > > > > > > > > > > > > > > > > > > > > > > Let's simplify Ignite codebase and drop client nodes! > > > > > > > > > > > > > > > > > > > > > > How does it sound? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > В Пн, 17/06/2019 в 15:52 +0300, Alexey Goncharuk пишет: > > > > > > > > > > > > Nikolay, > > > > > > > > > > > > > > > > > > > > > > > > Local caches and scalar are already in the list :) > > Added > > > > the > > > > > > > outdated > > > > > > > > > > > > metrics point. > > > > > > > > > > > > > > > > > > > > > > > > пн, 17 июн. 2019 г. в 15:32, Nikolay Izhikov < > > > > > > > nizhi...@apache.org>: > > > > > > > > > > > > > > > > > > > > > > > > > * Scalar. > > > > > > > > > > > > > * LOCAL caches. > > > > > > > > > > > > > * Deprecated metrics. > > > > > > > > > > > > > > > > > > > > > > > > > > В Пн, 17/06/2019 в 15:18 +0300, Alexey Goncharuk > > пишет: > > > > > > > > > > > > > > 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 inspired > by > > > > Denis > > > > > > > Magda's > > > > > > > > > > > > > > > > > > > > > > IGFS > > > > > > > > > > > > > > removal thread). I've separated all to-be-removed > > > > 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 are > > 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
