Hi Ivan, thank you for this bit of information. We seem to be on the same page about a removal, and it would not happen in 3.0. My concern related to public API and users. If we internally redesign thick clients and remove counter-intuitive use cases (e.g. caches on a client, excepting near caches) it is perfectly fine, and I encourage everyone to propose solutions in this issue.
Hi Andrey, please check your Apache ID while login to wiki. Since you are comitter you should be able to edit (INFRA set up LDAP recently). If it will not work, please share your wiki username, and I will add permissions. Sincerely Dmitriy Pavlov вт, 18 июн. 2019 г. в 12:32, Павлухин Иван <vololo...@gmail.com>: > 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. > > вт, 18 июн. 2019 г. в 11:42, Andrey Mashenkov <andrey.mashen...@gmail.com > >: > > > > 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 > > > > -- > Best regards, > Ivan Pavlukhin >
