ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nikolay Izhikov <nizhi...@apache.org>
Subject Re: [DISCUSSION] Ignite 3.0 and to be removed list
Date Mon, 17 Jun 2019 15:32:38 GMT
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
View raw message