ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrey Mashenkov <andrey.mashen...@gmail.com>
Subject Re: [DISCUSSION] Ignite 3.0 and to be removed list
Date Tue, 18 Jun 2019 08:42:15 GMT
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.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?
>
> вт, 18 июн. 2019 г. в 00:19, Alex Plehanov <plehanov.alex@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 <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?
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>


-- 
Best regards,
Andrey V. Mashenkov

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