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? > > > > > >
