ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Plehanov <plehanov.a...@gmail.com>
Subject Re: [DISCUSSION] Ignite 3.0 and to be removed list
Date Mon, 17 Jun 2019 21:19:16 GMT
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 <ptupitsyn@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 <isapego@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 <jokserfn@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 <dpavlov@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 <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 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.sin@gmail.com
> > > >:
> > > > > >
> > > > > > > Could we suggest here remove whole modules?
> > > > > > >
> > > > > > > пн, 17 июн. 2019 г. в 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 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
<
> > > nizhikov@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 <
> > > > > nizhikov@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?
> > > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message