Apache Ignite Developers - Legacy Mail Archive

[DISCUSSION] Ignite 3.0 and to be removed list

Classic

List

Threaded

52 messages Options

123

Dmitry Pavlov

Re: [DISCUSSION] Ignite 3.0 and to be removed list

We found an issue, we never set up group access before:
now committers (wiki group: ignite) can edit and create pages, and PMC
members (wiki group: ignite-pmc) are admins.

Andrey, could you confirm you can edit now?

вт, 18 июн. 2019 г. в 13:33, Dmitriy Pavlov <[hidden email]>:

> 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, Павлухин Иван <[hidden email]>:
>
>> 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 <[hidden email]
>> >:
>> >
>> > 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 <
>> > [hidden email]> 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 <[hidden email]>:
>> > >
>> > > > 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 <[hidden email]>:
>> > > >
>> > > > > 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 <[hidden email]
>> >
>> > > > 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 <
>> [hidden email]>
>> > > > > > 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 <
>> [hidden email]>:
>> > > > > > >
>> > > > > > > > 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 <
>> > > [hidden email]
>> > > > >:
>> > > > > > > >
>> > > > > > > > > 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 <
>> > > > > > [hidden email]
>> > > > > > > >:
>> > > > > > > > > >
>> > > > > > > > > > > Could we suggest here remove whole modules?
>> > > > > > > > > > >
>> > > > > > > > > > > пн, 17 июн. 2019 г. в 16:28, Alexey Goncharuk <
>> > > > > > > > > [hidden email]
>> > > > > > > > > > > > :
>> > > > > > > > > > > > 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 <
>> > > > > > > [hidden email]
>> > > > > > > > >:
>> > > > > > > > > > > >
>> > > > > > > > > > > > > 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 <
>> > > > > > > > > [hidden email]>:
>> > > > > > > > > > > > > >
>> > > > > > > > > > > > > > > * 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
>>
>

dmagda

Re: [DISCUSSION] Ignite 3.0 and to be removed list

In reply to this post by Alexey Goncharuk-3

Alex,

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.

Could you please share a reference to the wishlist? It's not in your
original email nor anywhere else in the discussion.

Generally speaking, I would group to-be-removed capabilities by Components,
Integrations, and APIs. Here is how my list looks like:

1. Components - IGFS and In-Memory Hadoop Accelerator. Strongly suggest
we to not putting off this procedure until 3.0 but execute the decision in
the next Ignite release. Refer to this thread [1] for details.
2. Integrations (aka. modules or plugins):
- Remove completely OR move to Github cemetery and no longer support
for every Ignite releases: Twitter, ZeroMQ, RocketMQ, Storm,
Flume, Flink,
MQTT, Camel, Hibernate, JMS, OSGi, YARN, Mesos, AOP-Based Grid
<https://apacheignite.readme.io/docs/aop-based-grid-enabling>,
ignite-clients
module <https://github.com/apache/ignite/tree/master/modules/clients>
- Preserve and move to separate repositories (to be supported by the
community). The goal is to separate Ignite core from
modules/plugins: Spark
Integration, TensorFlow, Cassandra Integration (ING), SpringData,
SpringBoot, Spring Caching, Kafka Integration.
- Move to separate repositories: thin clients (at least non-Java ones)
3. APIs:
- Remove: Redis and Memcached protocols support, compute
checkpointing SPI, geospatial support
- Should we remove the following or invest our time in better
support? - full-text search, Ignite messaging

I would put all of the suggestions on the wiki or on that wishlist and
track everything there while the discussion continues.

[1]
http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Complete-Discontinuation-of-IGFS-and-Hadoop-Accelerator-td42282.html

-
Denis

On Mon, Jun 17, 2019 at 5:18 AM Alexey Goncharuk <[hidden email]>
wrote:

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

Dmitry Pavlov

Re: [DISCUSSION] Ignite 3.0 and to be removed list

Denis, here is the link:
https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist

вт, 18 июн. 2019 г. в 21:28, Denis Magda <[hidden email]>:

> Alex,
>
> 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.
>
>
> Could you please share a reference to the wishlist? It's not in your
> original email nor anywhere else in the discussion.
>
> Generally speaking, I would group to-be-removed capabilities by Components,
> Integrations, and APIs. Here is how my list looks like:
>
> 1. Components - IGFS and In-Memory Hadoop Accelerator. Strongly suggest
> we to not putting off this procedure until 3.0 but execute the decision
> in
> the next Ignite release. Refer to this thread [1] for details.
> 2. Integrations (aka. modules or plugins):
> - Remove completely OR move to Github cemetery and no longer support
> for every Ignite releases: Twitter, ZeroMQ, RocketMQ, Storm,
> Flume, Flink,
> MQTT, Camel, Hibernate, JMS, OSGi, YARN, Mesos, AOP-Based Grid
> <https://apacheignite.readme.io/docs/aop-based-grid-enabling>,
> ignite-clients
> module <https://github.com/apache/ignite/tree/master/modules/clients
> >
> - Preserve and move to separate repositories (to be supported by the
> community). The goal is to separate Ignite core from
> modules/plugins: Spark
> Integration, TensorFlow, Cassandra Integration (ING), SpringData,
> SpringBoot, Spring Caching, Kafka Integration.
> - Move to separate repositories: thin clients (at least non-Java
> ones)
> 3. APIs:
> - Remove: Redis and Memcached protocols support, compute
> checkpointing SPI, geospatial support
> - Should we remove the following or invest our time in better
> support? - full-text search, Ignite messaging
>
>
> I would put all of the suggestions on the wiki or on that wishlist and
> track everything there while the discussion continues.
>
> [1]
>
> http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Complete-Discontinuation-of-IGFS-and-Hadoop-Accelerator-td42282.html
>
> -
> Denis
>
>
> On Mon, Jun 17, 2019 at 5:18 AM Alexey Goncharuk <[hidden email]>
> wrote:
>
> > 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?
> >
> > --AG
> >
>

dmagda

Re: [DISCUSSION] Ignite 3.0 and to be removed list

In reply to this post by Alexey Goncharuk

+1

Thick (aka. standard clients) provide comprehensive compute APIs with
peer-class-loading. That's a huge differentiator for Ignite. Until thin
clients support compute and ML API at the same level as the standard client
does, I would not consider the standard clients' discontinuation. Plus, as
Alex outlined, a functional gap is even wider.

-
Denis

On Mon, Jun 17, 2019 at 6:28 AM Alexey Goncharuk <[hidden email]>
wrote:

> 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 <[hidden email]>:
>
> > 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 <[hidden email]>:
> > >
> > > > * 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?
> >
>

Ivan Pavlukhin

Re: [DISCUSSION] Ignite 3.0 and to be removed list

Do we still need onheap caches?

вт, 18 июн. 2019 г. в 21:30, Denis Magda <[hidden email]>:

>
> +1
>
> Thick (aka. standard clients) provide comprehensive compute APIs with
> peer-class-loading. That's a huge differentiator for Ignite. Until thin
> clients support compute and ML API at the same level as the standard client
> does, I would not consider the standard clients' discontinuation. Plus, as
> Alex outlined, a functional gap is even wider.
>
> -
> Denis
>
>
> On Mon, Jun 17, 2019 at 6:28 AM Alexey Goncharuk <[hidden email]>
> wrote:
>
> > 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 <[hidden email]>:
> >
> > > 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 <[hidden email]>:
> > > >
> > > > > * 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,
Ivan Pavlukhin

dmagda

Re: [DISCUSSION] Ignite 3.0 and to be removed list

Ivan,

I believe that, yes, those caches are still extremely useful for
low-latency use cases. Companies are ready to allocate more RAM in favor of
lower latencies because off-heap access is still slower than the on-heap
one. There are not that many use case of this kind, but I can recall
several companies that exploit on-heap caching a lot.

-
Denis

On Tue, Jun 18, 2019 at 11:42 AM Павлухин Иван <[hidden email]> wrote:

> Do we still need onheap caches?
>
> вт, 18 июн. 2019 г. в 21:30, Denis Magda <[hidden email]>:
> >
> > +1
> >
> > Thick (aka. standard clients) provide comprehensive compute APIs with
> > peer-class-loading. That's a huge differentiator for Ignite. Until thin
> > clients support compute and ML API at the same level as the standard
> client
> > does, I would not consider the standard clients' discontinuation. Plus,
> as
> > Alex outlined, a functional gap is even wider.
> >
> > -
> > Denis
> >
> >
> > On Mon, Jun 17, 2019 at 6:28 AM Alexey Goncharuk <
> [hidden email]>
> > wrote:
> >
> > > 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 <[hidden email]>:
> > >
> > > > 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 <[hidden email]
> >:
> > > > >
> > > > > > * 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,
> Ivan Pavlukhin
>

Dmitry Pavlov

Re: [DISCUSSION] Ignite 3.0 and to be removed list

+1 to Denis, Near caches are on-heap, as well, so I guess we need it.

BTW, TeamCity Bot uses Guava on-heap caching above Ignite (Durable Memory).
This is because keeping the same instance of Java object cached brings a
visible performance boost for really hot code points. At least, it reduces
GC pressure. Offheap->onheap unmarshalling gives new object from JVM point
of view.

ср, 19 июн. 2019 г. в 00:35, Denis Magda <[hidden email]>:

> Ivan,
>
> I believe that, yes, those caches are still extremely useful for
> low-latency use cases. Companies are ready to allocate more RAM in favor of
> lower latencies because off-heap access is still slower than the on-heap
> one. There are not that many use case of this kind, but I can recall
> several companies that exploit on-heap caching a lot.
>
> -
> Denis
>
>
> On Tue, Jun 18, 2019 at 11:42 AM Павлухин Иван <[hidden email]>
> wrote:
>
> > Do we still need onheap caches?
> >
> > вт, 18 июн. 2019 г. в 21:30, Denis Magda <[hidden email]>:
> > >
> > > +1
> > >
> > > Thick (aka. standard clients) provide comprehensive compute APIs with
> > > peer-class-loading. That's a huge differentiator for Ignite. Until thin
> > > clients support compute and ML API at the same level as the standard
> > client
> > > does, I would not consider the standard clients' discontinuation. Plus,
> > as
> > > Alex outlined, a functional gap is even wider.
> > >
> > > -
> > > Denis
> > >
> > >
> > > On Mon, Jun 17, 2019 at 6:28 AM Alexey Goncharuk <
> > [hidden email]>
> > > wrote:
> > >
> > > > 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 <[hidden email]>:
> > > >
> > > > > 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 <
> [hidden email]
> > >:
> > > > > >
> > > > > > > * 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,
> > Ivan Pavlukhin
> >
>

Ilya Kasnacheev

Re: [DISCUSSION] Ignite 3.0 and to be removed list

In reply to this post by dmagda

Hello!

I think that Hibernate and MongoDB support should go not to cemetery but to
separate repositories to be supported. They see quite a few demand.

Regards,
--
Ilya Kasnacheev

вт, 18 июн. 2019 г. в 21:28, Denis Magda <[hidden email]>:

Roman Shtykh

Re: [DISCUSSION] Ignite 3.0 and to be removed list

Probably it makes sense to have a survey on users mailing list to have some idea what is being used before deciding what to bury, support in a separate repository or master branch.

-- Roman

On Thursday, June 20, 2019, 10:26:37 p.m. GMT+9, Ilya Kasnacheev <[hidden email]> wrote:

Hello!

I think that Hibernate and MongoDB support should go not to cemetery but to
separate repositories to be supported. They see quite a few demand.

Regards,
--
Ilya Kasnacheev

вт, 18 июн. 2019 г. в 21:28, Denis Magda <[hidden email]>:

Dmitry Melnichuk

Re: [DISCUSSION] Ignite 3.0 and to be removed list

In reply to this post by Alexey Goncharuk-3

Hello Igniters,

I'd like to add my ¢2 considering Python thin client.

I think we should abandon Python 3.4, which was a precondition from
Ignite community when I started to work on `pyignite` a good year ago,
and update the minimum requirement to at least Python 3.6, or, better
yet, 3.7.

Reasons to do so:

1. Python 3.4 has reached its EOL this Spring. The final build was
released: March 18, 2019. PIP, setuptools, PyCharm are already dropped
their support for Python 3.4. In other words, bits have started to rot.

2. Python 3.4 builds against OpenSSL 1.0, while 3.5+ − OpenSSL 1.1. If
we intend to support TLS 1.3 encryption in Python thin client, we
should move on from Python 3.4.

3. The most important part for me as a developer: positive changes in
the language itself. To name only a few:

- `dict` and `OrderedDict` types was merged within one highly-optimized
C implementation,

- `typing` module (type annotations support) was built into the
language and significantly improved,

- string interpolation (so-called “f-strings”) and data classes was
introduced in 3.6.

If there is at least one good reason to support Python 3.4, I would
like to learn about it. Otherwise, the struggle for supporting the
outdated language version seems pointless to me.

On Mon, 2019-06-17 at 15:18 +0300, Alexey Goncharuk wrote:

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

Dmitry Melnichuk

Re: [DISCUSSION] Ignite 3.0 and to be removed list

In reply to this post by Dmitry Pavlov

Dmitry,
As a Python thin client developer, I think that separate repository is
a truly great idea!
On Tue, 2019-06-18 at 21:29 +0300, Dmitriy Pavlov wrote:
> - Move to separate repositories: thin clients (at least non-Java
>
> > ones)

Alexey Goncharuk

Re: [DISCUSSION] Ignite 3.0 and to be removed list

Anton,

I would like to pull-up the discussion regarding the near caches - I cannot
agree this is a feature that needs to be removed. Near caches provide
significant read performance improvements and, to the best of my knowledge,
are used in several cases in production. Can you elaborate on the
shortcomings you faced? Maybe we can improve both internal code and user
experience?

пт, 21 июн. 2019 г. в 10:42, Dmitry Melnichuk <
[hidden email]>:

> Dmitry,
> As a Python thin client developer, I think that separate repository is
> a truly great idea!
> On Tue, 2019-06-18 at 21:29 +0300, Dmitriy Pavlov wrote:
> > - Move to separate repositories: thin clients (at least non-Java
> >
> > > ones)
>

Anton Vinogradov-2

Re: [DISCUSSION] Ignite 3.0 and to be removed list

Alexey,

Thank's for keeping an eye on page updates.
Near Caches is not a bad feature, but it should be used with caution.
At least we have to explain how it works on readme.io, why and when it
should be used because usage can drop the performance instead of increasing
it.

Anyway, I added near caches because I never heard someone used them
meaningfully, not like a silver bullet.
So, that's just a proposal :)

Also, I'd like to propose to have some voting about full list later to gain
"must be removed", "can be removed" and "should be kept" lists.

On Thu, Jun 27, 2019 at 1:03 PM Alexey Goncharuk <[hidden email]>
wrote:

> Anton,
>
> I would like to pull-up the discussion regarding the near caches - I cannot
> agree this is a feature that needs to be removed. Near caches provide
> significant read performance improvements and, to the best of my knowledge,
> are used in several cases in production. Can you elaborate on the
> shortcomings you faced? Maybe we can improve both internal code and user
> experience?
>
> пт, 21 июн. 2019 г. в 10:42, Dmitry Melnichuk <
> [hidden email]>:
>
> > Dmitry,
> > As a Python thin client developer, I think that separate repository is
> > a truly great idea!
> > On Tue, 2019-06-18 at 21:29 +0300, Dmitriy Pavlov wrote:
> > > - Move to separate repositories: thin clients (at least non-Java
> > >
> > > > ones)
> >
>

Alexey Goncharuk

Re: [DISCUSSION] Ignite 3.0 and to be removed list

Anton, good point.

Do you have any idea how we can keep track of the voting? Should we launch
a google survey or survey monkey? Voting by email?

пт, 28 июн. 2019 г. в 11:24, Anton Vinogradov <[hidden email]>:

> Alexey,
>
> Thank's for keeping an eye on page updates.
> Near Caches is not a bad feature, but it should be used with caution.
> At least we have to explain how it works on readme.io, why and when it
> should be used because usage can drop the performance instead of increasing
> it.
>
> Anyway, I added near caches because I never heard someone used them
> meaningfully, not like a silver bullet.
> So, that's just a proposal :)
>
> Also, I'd like to propose to have some voting about full list later to gain
> "must be removed", "can be removed" and "should be kept" lists.
>
> On Thu, Jun 27, 2019 at 1:03 PM Alexey Goncharuk <
> [hidden email]>
> wrote:
>
> > Anton,
> >
> > I would like to pull-up the discussion regarding the near caches - I
> cannot
> > agree this is a feature that needs to be removed. Near caches provide
> > significant read performance improvements and, to the best of my
> knowledge,
> > are used in several cases in production. Can you elaborate on the
> > shortcomings you faced? Maybe we can improve both internal code and user
> > experience?
> >
> > пт, 21 июн. 2019 г. в 10:42, Dmitry Melnichuk <
> > [hidden email]>:
> >
> > > Dmitry,
> > > As a Python thin client developer, I think that separate repository is
> > > a truly great idea!
> > > On Tue, 2019-06-18 at 21:29 +0300, Dmitriy Pavlov wrote:
> > > > - Move to separate repositories: thin clients (at least non-Java
> > > >
> > > > > ones)
> > >
> >
>

dmagda

Re: [DISCUSSION] Ignite 3.0 and to be removed list

Alex,

I would do an email survey to hear an opinion of why someone believes a
feature A has to stay. It makes sense to ask about the APIs to be removed
as well as integrations to go out of community support [1] in the same
thread.

Has everyone expressed an opinion? If yes, I can go ahead and format the
wishlist page and make it structured for the user thread.

[1]
http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-Modularization-td42486.html
-
Denis

On Fri, Jun 28, 2019 at 8:54 AM Alexey Goncharuk <[hidden email]>
wrote:

> Anton, good point.
>
> Do you have any idea how we can keep track of the voting? Should we launch
> a google survey or survey monkey? Voting by email?
>
> пт, 28 июн. 2019 г. в 11:24, Anton Vinogradov <[hidden email]>:
>
> > Alexey,
> >
> > Thank's for keeping an eye on page updates.
> > Near Caches is not a bad feature, but it should be used with caution.
> > At least we have to explain how it works on readme.io, why and when it
> > should be used because usage can drop the performance instead of
> increasing
> > it.
> >
> > Anyway, I added near caches because I never heard someone used them
> > meaningfully, not like a silver bullet.
> > So, that's just a proposal :)
> >
> > Also, I'd like to propose to have some voting about full list later to
> gain
> > "must be removed", "can be removed" and "should be kept" lists.
> >
> > On Thu, Jun 27, 2019 at 1:03 PM Alexey Goncharuk <
> > [hidden email]>
> > wrote:
> >
> > > Anton,
> > >
> > > I would like to pull-up the discussion regarding the near caches - I
> > cannot
> > > agree this is a feature that needs to be removed. Near caches provide
> > > significant read performance improvements and, to the best of my
> > knowledge,
> > > are used in several cases in production. Can you elaborate on the
> > > shortcomings you faced? Maybe we can improve both internal code and
> user
> > > experience?
> > >
> > > пт, 21 июн. 2019 г. в 10:42, Dmitry Melnichuk <
> > > [hidden email]>:
> > >
> > > > Dmitry,
> > > > As a Python thin client developer, I think that separate repository
> is
> > > > a truly great idea!
> > > > On Tue, 2019-06-18 at 21:29 +0300, Dmitriy Pavlov wrote:
> > > > > - Move to separate repositories: thin clients (at least non-Java
> > > > >
> > > > > > ones)
> > > >
> > >
> >
>

Anton Vinogradov-2

Re: [DISCUSSION] Ignite 3.0 and to be removed list

+1 to email survey with following types of votes
- silence (agree with all proposed removals)
- we have to keep XXX because ...

As a result, will gain lists
"to be removed" - no one objected
"can be removed" - single objection
"should be kept" - multi objections

Denis or Dmitry Pavlov, could you please lead this thread?

On Sat, Jun 29, 2019 at 12:27 AM Denis Magda <[hidden email]> wrote:

> Alex,
>
> I would do an email survey to hear an opinion of why someone believes a
> feature A has to stay. It makes sense to ask about the APIs to be removed
> as well as integrations to go out of community support [1] in the same
> thread.
>
> Has everyone expressed an opinion? If yes, I can go ahead and format the
> wishlist page and make it structured for the user thread.
>
> [1]
>
> http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-Modularization-td42486.html
> -
> Denis
>
>
> On Fri, Jun 28, 2019 at 8:54 AM Alexey Goncharuk <
> [hidden email]>
> wrote:
>
> > Anton, good point.
> >
> > Do you have any idea how we can keep track of the voting? Should we
> launch
> > a google survey or survey monkey? Voting by email?
> >
> > пт, 28 июн. 2019 г. в 11:24, Anton Vinogradov <[hidden email]>:
> >
> > > Alexey,
> > >
> > > Thank's for keeping an eye on page updates.
> > > Near Caches is not a bad feature, but it should be used with caution.
> > > At least we have to explain how it works on readme.io, why and when it
> > > should be used because usage can drop the performance instead of
> > increasing
> > > it.
> > >
> > > Anyway, I added near caches because I never heard someone used them
> > > meaningfully, not like a silver bullet.
> > > So, that's just a proposal :)
> > >
> > > Also, I'd like to propose to have some voting about full list later to
> > gain
> > > "must be removed", "can be removed" and "should be kept" lists.
> > >
> > > On Thu, Jun 27, 2019 at 1:03 PM Alexey Goncharuk <
> > > [hidden email]>
> > > wrote:
> > >
> > > > Anton,
> > > >
> > > > I would like to pull-up the discussion regarding the near caches - I
> > > cannot
> > > > agree this is a feature that needs to be removed. Near caches provide
> > > > significant read performance improvements and, to the best of my
> > > knowledge,
> > > > are used in several cases in production. Can you elaborate on the
> > > > shortcomings you faced? Maybe we can improve both internal code and
> > user
> > > > experience?
> > > >
> > > > пт, 21 июн. 2019 г. в 10:42, Dmitry Melnichuk <
> > > > [hidden email]>:
> > > >
> > > > > Dmitry,
> > > > > As a Python thin client developer, I think that separate repository
> > is
> > > > > a truly great idea!
> > > > > On Tue, 2019-06-18 at 21:29 +0300, Dmitriy Pavlov wrote:
> > > > > > - Move to separate repositories: thin clients (at least non-Java
> > > > > >
> > > > > > > ones)
> > > > >
> > > >
> > >
> >
>

Dmitry Pavlov

Re: [DISCUSSION] Ignite 3.0 and to be removed list

I propose each removal should have separated formal vote thread with
consensus approval (since it is code modification).

This means a single binding objection with justification is a blocker for
removal.

We need separation to let community members pick up an interesting topic
from email subject. Not all members reading carefully each post in
mile-long threads.

пн, 1 июл. 2019 г. в 11:17, Anton Vinogradov <[hidden email]>:

> +1 to email survey with following types of votes
> - silence (agree with all proposed removals)
> - we have to keep XXX because ...
>
> As a result, will gain lists
> "to be removed" - no one objected
> "can be removed" - single objection
> "should be kept" - multi objections
>
> Denis or Dmitry Pavlov, could you please lead this thread?
>
> On Sat, Jun 29, 2019 at 12:27 AM Denis Magda <[hidden email]> wrote:
>
> > Alex,
> >
> > I would do an email survey to hear an opinion of why someone believes a
> > feature A has to stay. It makes sense to ask about the APIs to be removed
> > as well as integrations to go out of community support [1] in the same
> > thread.
> >
> > Has everyone expressed an opinion? If yes, I can go ahead and format the
> > wishlist page and make it structured for the user thread.
> >
> > [1]
> >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-Modularization-td42486.html
> > -
> > Denis
> >
> >
> > On Fri, Jun 28, 2019 at 8:54 AM Alexey Goncharuk <
> > [hidden email]>
> > wrote:
> >
> > > Anton, good point.
> > >
> > > Do you have any idea how we can keep track of the voting? Should we
> > launch
> > > a google survey or survey monkey? Voting by email?
> > >
> > > пт, 28 июн. 2019 г. в 11:24, Anton Vinogradov <[hidden email]>:
> > >
> > > > Alexey,
> > > >
> > > > Thank's for keeping an eye on page updates.
> > > > Near Caches is not a bad feature, but it should be used with caution.
> > > > At least we have to explain how it works on readme.io, why and when
> it
> > > > should be used because usage can drop the performance instead of
> > > increasing
> > > > it.
> > > >
> > > > Anyway, I added near caches because I never heard someone used them
> > > > meaningfully, not like a silver bullet.
> > > > So, that's just a proposal :)
> > > >
> > > > Also, I'd like to propose to have some voting about full list later
> to
> > > gain
> > > > "must be removed", "can be removed" and "should be kept" lists.
> > > >
> > > > On Thu, Jun 27, 2019 at 1:03 PM Alexey Goncharuk <
> > > > [hidden email]>
> > > > wrote:
> > > >
> > > > > Anton,
> > > > >
> > > > > I would like to pull-up the discussion regarding the near caches -
> I
> > > > cannot
> > > > > agree this is a feature that needs to be removed. Near caches
> provide
> > > > > significant read performance improvements and, to the best of my
> > > > knowledge,
> > > > > are used in several cases in production. Can you elaborate on the
> > > > > shortcomings you faced? Maybe we can improve both internal code and
> > > user
> > > > > experience?
> > > > >
> > > > > пт, 21 июн. 2019 г. в 10:42, Dmitry Melnichuk <
> > > > > [hidden email]>:
> > > > >
> > > > > > Dmitry,
> > > > > > As a Python thin client developer, I think that separate
> repository
> > > is
> > > > > > a truly great idea!
> > > > > > On Tue, 2019-06-18 at 21:29 +0300, Dmitriy Pavlov wrote:
> > > > > > > - Move to separate repositories: thin clients (at least
> non-Java
> > > > > > >
> > > > > > > > ones)
> > > > > >
> > > > >
> > > >
> > >
> >
>

dmagda

Re: [DISCUSSION] Ignite 3.0 and to be removed list

I wouldn't kick off dozens of voting discussions. Instead, the content on
the wiki page needs to be cleaned and rearranged. This will make the
content readable and comprehensible. I can do that.

Next, let's ask the user community for an opinion. After reviewing and
incorporating the latter we can do one more dev list discussion with the
last call for opinions. Next, will be the voting time. If there is a
feature someone from the dev list is against of removing, then we can start
a separate vote for it later. But let's get into those cases first.

-
Denis

On Mon, Jul 1, 2019 at 1:47 AM Dmitriy Pavlov <[hidden email]> wrote:

> I propose each removal should have separated formal vote thread with
> consensus approval (since it is code modification).
>
> This means a single binding objection with justification is a blocker for
> removal.
>
> We need separation to let community members pick up an interesting topic
> from email subject. Not all members reading carefully each post in
> mile-long threads.
>
> пн, 1 июл. 2019 г. в 11:17, Anton Vinogradov <[hidden email]>:
>
> > +1 to email survey with following types of votes
> > - silence (agree with all proposed removals)
> > - we have to keep XXX because ...
> >
> > As a result, will gain lists
> > "to be removed" - no one objected
> > "can be removed" - single objection
> > "should be kept" - multi objections
> >
> > Denis or Dmitry Pavlov, could you please lead this thread?
> >
> > On Sat, Jun 29, 2019 at 12:27 AM Denis Magda <[hidden email]> wrote:
> >
> > > Alex,
> > >
> > > I would do an email survey to hear an opinion of why someone believes a
> > > feature A has to stay. It makes sense to ask about the APIs to be
> removed
> > > as well as integrations to go out of community support [1] in the same
> > > thread.
> > >
> > > Has everyone expressed an opinion? If yes, I can go ahead and format
> the
> > > wishlist page and make it structured for the user thread.
> > >
> > > [1]
> > >
> > >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-Modularization-td42486.html
> > > -
> > > Denis
> > >
> > >
> > > On Fri, Jun 28, 2019 at 8:54 AM Alexey Goncharuk <
> > > [hidden email]>
> > > wrote:
> > >
> > > > Anton, good point.
> > > >
> > > > Do you have any idea how we can keep track of the voting? Should we
> > > launch
> > > > a google survey or survey monkey? Voting by email?
> > > >
> > > > пт, 28 июн. 2019 г. в 11:24, Anton Vinogradov <[hidden email]>:
> > > >
> > > > > Alexey,
> > > > >
> > > > > Thank's for keeping an eye on page updates.
> > > > > Near Caches is not a bad feature, but it should be used with
> caution.
> > > > > At least we have to explain how it works on readme.io, why and
> when
> > it
> > > > > should be used because usage can drop the performance instead of
> > > > increasing
> > > > > it.
> > > > >
> > > > > Anyway, I added near caches because I never heard someone used them
> > > > > meaningfully, not like a silver bullet.
> > > > > So, that's just a proposal :)
> > > > >
> > > > > Also, I'd like to propose to have some voting about full list later
> > to
> > > > gain
> > > > > "must be removed", "can be removed" and "should be kept" lists.
> > > > >
> > > > > On Thu, Jun 27, 2019 at 1:03 PM Alexey Goncharuk <
> > > > > [hidden email]>
> > > > > wrote:
> > > > >
> > > > > > Anton,
> > > > > >
> > > > > > I would like to pull-up the discussion regarding the near caches
> -
> > I
> > > > > cannot
> > > > > > agree this is a feature that needs to be removed. Near caches
> > provide
> > > > > > significant read performance improvements and, to the best of my
> > > > > knowledge,
> > > > > > are used in several cases in production. Can you elaborate on the
> > > > > > shortcomings you faced? Maybe we can improve both internal code
> and
> > > > user
> > > > > > experience?
> > > > > >
> > > > > > пт, 21 июн. 2019 г. в 10:42, Dmitry Melnichuk <
> > > > > > [hidden email]>:
> > > > > >
> > > > > > > Dmitry,
> > > > > > > As a Python thin client developer, I think that separate
> > repository
> > > > is
> > > > > > > a truly great idea!
> > > > > > > On Tue, 2019-06-18 at 21:29 +0300, Dmitriy Pavlov wrote:
> > > > > > > > - Move to separate repositories: thin clients (at least
> > non-Java
> > > > > > > >
> > > > > > > > > ones)
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Alexey Goncharuk

Re: [DISCUSSION] Ignite 3.0 and to be removed list

Denis,

Are we ready to present the list to the user list?

вт, 2 июл. 2019 г. в 00:27, Denis Magda <[hidden email]>:

> I wouldn't kick off dozens of voting discussions. Instead, the content on
> the wiki page needs to be cleaned and rearranged. This will make the
> content readable and comprehensible. I can do that.
>
> Next, let's ask the user community for an opinion. After reviewing and
> incorporating the latter we can do one more dev list discussion with the
> last call for opinions. Next, will be the voting time. If there is a
> feature someone from the dev list is against of removing, then we can start
> a separate vote for it later. But let's get into those cases first.
>
> -
> Denis
>
>
> On Mon, Jul 1, 2019 at 1:47 AM Dmitriy Pavlov <[hidden email]> wrote:
>
> > I propose each removal should have separated formal vote thread with
> > consensus approval (since it is code modification).
> >
> > This means a single binding objection with justification is a blocker for
> > removal.
> >
> > We need separation to let community members pick up an interesting topic
> > from email subject. Not all members reading carefully each post in
> > mile-long threads.
> >
> > пн, 1 июл. 2019 г. в 11:17, Anton Vinogradov <[hidden email]>:
> >
> > > +1 to email survey with following types of votes
> > > - silence (agree with all proposed removals)
> > > - we have to keep XXX because ...
> > >
> > > As a result, will gain lists
> > > "to be removed" - no one objected
> > > "can be removed" - single objection
> > > "should be kept" - multi objections
> > >
> > > Denis or Dmitry Pavlov, could you please lead this thread?
> > >
> > > On Sat, Jun 29, 2019 at 12:27 AM Denis Magda <[hidden email]>
> wrote:
> > >
> > > > Alex,
> > > >
> > > > I would do an email survey to hear an opinion of why someone
> believes a
> > > > feature A has to stay. It makes sense to ask about the APIs to be
> > removed
> > > > as well as integrations to go out of community support [1] in the
> same
> > > > thread.
> > > >
> > > > Has everyone expressed an opinion? If yes, I can go ahead and format
> > the
> > > > wishlist page and make it structured for the user thread.
> > > >
> > > > [1]
> > > >
> > > >
> > >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-Modularization-td42486.html
> > > > -
> > > > Denis
> > > >
> > > >
> > > > On Fri, Jun 28, 2019 at 8:54 AM Alexey Goncharuk <
> > > > [hidden email]>
> > > > wrote:
> > > >
> > > > > Anton, good point.
> > > > >
> > > > > Do you have any idea how we can keep track of the voting? Should we
> > > > launch
> > > > > a google survey or survey monkey? Voting by email?
> > > > >
> > > > > пт, 28 июн. 2019 г. в 11:24, Anton Vinogradov <[hidden email]>:
> > > > >
> > > > > > Alexey,
> > > > > >
> > > > > > Thank's for keeping an eye on page updates.
> > > > > > Near Caches is not a bad feature, but it should be used with
> > caution.
> > > > > > At least we have to explain how it works on readme.io, why and
> > when
> > > it
> > > > > > should be used because usage can drop the performance instead of
> > > > > increasing
> > > > > > it.
> > > > > >
> > > > > > Anyway, I added near caches because I never heard someone used
> them
> > > > > > meaningfully, not like a silver bullet.
> > > > > > So, that's just a proposal :)
> > > > > >
> > > > > > Also, I'd like to propose to have some voting about full list
> later
> > > to
> > > > > gain
> > > > > > "must be removed", "can be removed" and "should be kept" lists.
> > > > > >
> > > > > > On Thu, Jun 27, 2019 at 1:03 PM Alexey Goncharuk <
> > > > > > [hidden email]>
> > > > > > wrote:
> > > > > >
> > > > > > > Anton,
> > > > > > >
> > > > > > > I would like to pull-up the discussion regarding the near
> caches
> > -
> > > I
> > > > > > cannot
> > > > > > > agree this is a feature that needs to be removed. Near caches
> > > provide
> > > > > > > significant read performance improvements and, to the best of
> my
> > > > > > knowledge,
> > > > > > > are used in several cases in production. Can you elaborate on
> the
> > > > > > > shortcomings you faced? Maybe we can improve both internal code
> > and
> > > > > user
> > > > > > > experience?
> > > > > > >
> > > > > > > пт, 21 июн. 2019 г. в 10:42, Dmitry Melnichuk <
> > > > > > > [hidden email]>:
> > > > > > >
> > > > > > > > Dmitry,
> > > > > > > > As a Python thin client developer, I think that separate
> > > repository
> > > > > is
> > > > > > > > a truly great idea!
> > > > > > > > On Tue, 2019-06-18 at 21:29 +0300, Dmitriy Pavlov wrote:
> > > > > > > > > - Move to separate repositories: thin clients (at least
> > > non-Java
> > > > > > > > >
> > > > > > > > > > ones)
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

dmagda

Re: [DISCUSSION] Ignite 3.0 and to be removed list

Alex, Igniters, sorry for a delay. Got swamped with other duties.

Does it wait till the next week? I'll make sure to dedicate some time for
that. Or if we'd like to run faster then I'll appreciate if someone else
steps in and prepares a list this week. I'll help to review and solidify it.

-
Denis

On Tue, Jul 16, 2019 at 7:58 AM Alexey Goncharuk <[hidden email]>
wrote:

> Denis,
>
> Are we ready to present the list to the user list?
>
> вт, 2 июл. 2019 г. в 00:27, Denis Magda <[hidden email]>:
>
> > I wouldn't kick off dozens of voting discussions. Instead, the content on
> > the wiki page needs to be cleaned and rearranged. This will make the
> > content readable and comprehensible. I can do that.
> >
> > Next, let's ask the user community for an opinion. After reviewing and
> > incorporating the latter we can do one more dev list discussion with the
> > last call for opinions. Next, will be the voting time. If there is a
> > feature someone from the dev list is against of removing, then we can
> start
> > a separate vote for it later. But let's get into those cases first.
> >
> > -
> > Denis
> >
> >
> > On Mon, Jul 1, 2019 at 1:47 AM Dmitriy Pavlov <[hidden email]>
> wrote:
> >
> > > I propose each removal should have separated formal vote thread with
> > > consensus approval (since it is code modification).
> > >
> > > This means a single binding objection with justification is a blocker
> for
> > > removal.
> > >
> > > We need separation to let community members pick up an interesting
> topic
> > > from email subject. Not all members reading carefully each post in
> > > mile-long threads.
> > >
> > > пн, 1 июл. 2019 г. в 11:17, Anton Vinogradov <[hidden email]>:
> > >
> > > > +1 to email survey with following types of votes
> > > > - silence (agree with all proposed removals)
> > > > - we have to keep XXX because ...
> > > >
> > > > As a result, will gain lists
> > > > "to be removed" - no one objected
> > > > "can be removed" - single objection
> > > > "should be kept" - multi objections
> > > >
> > > > Denis or Dmitry Pavlov, could you please lead this thread?
> > > >
> > > > On Sat, Jun 29, 2019 at 12:27 AM Denis Magda <[hidden email]>
> > wrote:
> > > >
> > > > > Alex,
> > > > >
> > > > > I would do an email survey to hear an opinion of why someone
> > believes a
> > > > > feature A has to stay. It makes sense to ask about the APIs to be
> > > removed
> > > > > as well as integrations to go out of community support [1] in the
> > same
> > > > > thread.
> > > > >
> > > > > Has everyone expressed an opinion? If yes, I can go ahead and
> format
> > > the
> > > > > wishlist page and make it structured for the user thread.
> > > > >
> > > > > [1]
> > > > >
> > > > >
> > > >
> > >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-Modularization-td42486.html
> > > > > -
> > > > > Denis
> > > > >
> > > > >
> > > > > On Fri, Jun 28, 2019 at 8:54 AM Alexey Goncharuk <
> > > > > [hidden email]>
> > > > > wrote:
> > > > >
> > > > > > Anton, good point.
> > > > > >
> > > > > > Do you have any idea how we can keep track of the voting? Should
> we
> > > > > launch
> > > > > > a google survey or survey monkey? Voting by email?
> > > > > >
> > > > > > пт, 28 июн. 2019 г. в 11:24, Anton Vinogradov <[hidden email]>:
> > > > > >
> > > > > > > Alexey,
> > > > > > >
> > > > > > > Thank's for keeping an eye on page updates.
> > > > > > > Near Caches is not a bad feature, but it should be used with
> > > caution.
> > > > > > > At least we have to explain how it works on readme.io, why and
> > > when
> > > > it
> > > > > > > should be used because usage can drop the performance instead
> of
> > > > > > increasing
> > > > > > > it.
> > > > > > >
> > > > > > > Anyway, I added near caches because I never heard someone used
> > them
> > > > > > > meaningfully, not like a silver bullet.
> > > > > > > So, that's just a proposal :)
> > > > > > >
> > > > > > > Also, I'd like to propose to have some voting about full list
> > later
> > > > to
> > > > > > gain
> > > > > > > "must be removed", "can be removed" and "should be kept" lists.
> > > > > > >
> > > > > > > On Thu, Jun 27, 2019 at 1:03 PM Alexey Goncharuk <
> > > > > > > [hidden email]>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Anton,
> > > > > > > >
> > > > > > > > I would like to pull-up the discussion regarding the near
> > caches
> > > -
> > > > I
> > > > > > > cannot
> > > > > > > > agree this is a feature that needs to be removed. Near caches
> > > > provide
> > > > > > > > significant read performance improvements and, to the best of
> > my
> > > > > > > knowledge,
> > > > > > > > are used in several cases in production. Can you elaborate on
> > the
> > > > > > > > shortcomings you faced? Maybe we can improve both internal
> code
> > > and
> > > > > > user
> > > > > > > > experience?
> > > > > > > >
> > > > > > > > пт, 21 июн. 2019 г. в 10:42, Dmitry Melnichuk <
> > > > > > > > [hidden email]>:
> > > > > > > >
> > > > > > > > > Dmitry,
> > > > > > > > > As a Python thin client developer, I think that separate
> > > > repository
> > > > > > is
> > > > > > > > > a truly great idea!
> > > > > > > > > On Tue, 2019-06-18 at 21:29 +0300, Dmitriy Pavlov wrote:
> > > > > > > > > > - Move to separate repositories: thin clients (at least
> > > > non-Java
> > > > > > > > > >
> > > > > > > > > > > ones)
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

123