You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Alexey Goncharuk <ag...@apache.org> on 2019/06/17 12:18:06 UTC
[DISCUSSION] Ignite 3.0 and to be removed list
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
Re: [DISCUSSION] Ignite 3.0 and to be removed list
Posted by Denis Magda <dm...@apache.org>.
Folks, I've seen that someone added Spark to the list of "Integrations for
Discontinuation". I wouldn't do this. IMO, Spark is one of the key
integrations along with Spring Data, TensorFlow, Kafka that should be moved
out of the core but to be supported by the community:
https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-IgniteModules
<https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-IgniteModules>
-
Denis
On Thu, Jul 25, 2019 at 1:21 AM Alexey Zinoviev <za...@gmail.com>
wrote:
> Thanks for the clarification, will try to vote
>
> чт, 25 июл. 2019 г. в 04:11, Denis Magda <dm...@gridgain.com>:
>
> > Alexey,
> >
> > I've changed format on the wiki so that every community member can cast
> +1
> > and -1 vote explaining his/her stance. This should help us to filter out
> > those integrations that everyone agrees to discontinue vs. those that are
> > controversial. Please, *everyone interested* share your opinion by
> putting
> > a name and +1/-1 in these tables:
> >
> > - Integrations for discontinuation:
> >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-IntegrationsforDiscontinuation
> > - APIs for removal:
> >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-APIsforRemoval
> >
> >
> >
> > 1. Exclude Spatial Indexes from API for removal (I don't know internal
> > > issues, but is I'd like this kind of index)
> >
> >
> > Both spatial and full-text search indexes provide limit support and not
> > integrated with Ignite's memory architecture. It's better for us to
> remove
> > them in Ignite 3.0 (that will go with a new API to be proposed soon by
> Alex
> > Goncharuk) and rebuild from scratch in 3.1/3.2.
> >
> >
> > > 2. Exclude Storm, Flume, Flink from Integrations for Discontinuation
> > > because I've ready to try support them (or dive in this question) I
> think
> > > no so many work to support them or move to the separate module like
> > > BigDataTools Integrations
> >
> >
> > Why don't we have them as separate Github projects that can be updated
> both
> > by the community members and independent developers? I just don't want
> this
> > to be a burden of the community to test and maintain it for every
> release.
> >
> > 3. Annotations based configuration of SQL - we should be careful with
> that,
> > > I suppose it's useful feature
> >
> >
> > Alex Goncharuk should propose a new API for 3.0 soon.
> >
> > 4. Ignite Messaging should be combined together with Kafka/different MQ
> > > integration into one module for messaging support
> >
> >
> > I wouldn't do this because 3rd party MQs go with their own versions that
> > start conflicting over the time. For instance, we already have several
> > modules for Hibernate and Spring Data integrations. To fix that, we just
> > need to store integrations in separate repos and do forks if a new
> > conflicting version has to be supported but there is still significant
> > usage of the old one.
> >
> > --
> > Denis Magda
> >
> >
> > On Tue, Jul 23, 2019 at 3:16 AM Alexey Zinoviev <za...@gmail.com>
> > wrote:
> >
> > > I have a few ideas, maybe somebody will support me
> > > 1. Exclude Spatial Indexes from API for removal (I don't know internal
> > > issues, but is I'd like this kind of index)
> > > 2. Exclude Storm, Flume, Flink from Integrations for Discontinuation
> > > because I've ready to try support them (or dive in this question) I
> think
> > > no so many work to support them or move to the separate module like
> > > BigDataTools Integrations
> > > 3. Annotations based configuration of SQL - we should be careful with
> > that,
> > > I suppose it's useful feature
> > > 4. Ignite Messaging should be combined together with Kafka/different MQ
> > > integration into one module for messaging support
> > >
> > > What do you think guys?
> > >
> > > пн, 22 июл. 2019 г. в 22:51, Denis Magda <dm...@apache.org>:
> > >
> > > > Igniters,
> > > >
> > > > I did the first run through the wishlist and selected integrations
> and
> > > APIs
> > > > for discontinuation. My suggestion would be to use IEP-36
> > > (Modularization)
> > > > page for the final list that we'll send to the user list for
> feedback:
> > > >
> > > > - Integrations for discontinuation:
> > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-IntegrationsforDiscontinuation
> > > > - APIs for removal:
> > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-APIsforRemoval
> > > >
> > > > Please check those lists and let us know if you have any arguments
> > > against
> > > > discontinuation/removal of X. Also, if you believe that something
> > listed
> > > in
> > > > the wishlist should be added to the EIP then let's discuss that.
> > > > Personally, I see the whishlist as a page with ideas while the IEP a
> > > final
> > > > plan for action.
> > > >
> > > >
> > > > -
> > > > Denis
> > > >
> > > >
> > > > On Mon, Jul 22, 2019 at 12:05 AM Vyacheslav Daradur <
> > daradurvs@gmail.com
> > > >
> > > > wrote:
> > > >
> > > > > I think all agreed items should be marked @Deprecated in the code
> > > > > base, so we will be able to remove them transparently for the
> > > > > end-users.
> > > > >
> > > > > On Mon, Jul 22, 2019 at 9:32 AM Павлухин Иван <vololo100@gmail.com
> >
> > > > wrote:
> > > > > >
> > > > > > Alex,
> > > > > >
> > > > > > I already added a couple of items to wishlist [1].
> > > > > >
> > > > > > Yes, I agree that the process should be iterative. But I am
> > confused
> > > > > > on what stage we are in a current interation? I suppose that
> Denis
> > is
> > > > > > going to present a list of removal candidates which we as
> > developers
> > > > > > agreed on. And should not we have that list already available
> > > > > > somewhere as a document? Now I see an infromation scattered in
> this
> > > > > > thread and the wishlist [1]. And it is not easy to me to realize
> > > where
> > > > > > we are now.
> > > > > >
> > > > > > [1]
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist
> > > > > >
> > > > > > чт, 18 июл. 2019 г. в 18:14, Alexey Goncharuk <
> > > > > alexey.goncharuk@gmail.com>:
> > > > > > >
> > > > > > > Ivan,
> > > > > > >
> > > > > > > The list is not final, we can still discuss and add more points
> > to
> > > be
> > > > > > > cleaned in 3.0. The more clear and understandable the API will
> > be,
> > > > the
> > > > > > > better. This thread was intended to draft the removal scope for
> > 3.0
> > > > > and to
> > > > > > > understand which portions will be definitely removed.
> > > > > > >
> > > > > > >
> > > > > > > ср, 17 июл. 2019 г. в 15:26, Павлухин Иван <
> vololo100@gmail.com
> > >:
> > > > > > >
> > > > > > > > Also, I did not quite get the point about JSR107 (JCache).
> From
> > > > time
> > > > > > > > to time I see on user-list threads where Ignite is used along
> > > with
> > > > > > > > Spring annotation-based cache integration. I suppose it
> > requires
> > > > > > > > JCache interfaces. What is crucially wrong with supporting
> it?
> > > > > > > >
> > > > > > > > ср, 17 июл. 2019 г. в 15:19, Павлухин Иван <
> > vololo100@gmail.com
> > > >:
> > > > > > > > >
> > > > > > > > > Folks,
> > > > > > > > >
> > > > > > > > > Sorry if I am repeating something. I checked a page [1] and
> > > have
> > > > > not
> > > > > > > > > found several items.
> > > > > > > > > 1. I thought that there was an agreement of dropping OLD
> > > service
> > > > > grid,
> > > > > > > > > was not it?
> > > > > > > > > 2. Also IndexingSpi seems to me as a candidate for removal.
> > > > > > > > >
> > > > > > > > > Should I add those items to the page? Or is there another
> > page
> > > > > > > > > containing items to be removed that we agreed on?
> > > > > > > > >
> > > > > > > > > [1]
> > > > > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist
> > > > > > > > >
> > > > > > > > > ср, 17 июл. 2019 г. в 02:00, Denis Magda <
> dmagda@apache.org
> > >:
> > > > > > > > > >
> > > > > > > > > > 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 <
> > > > > > > > alexey.goncharuk@gmail.com>
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Denis,
> > > > > > > > > > >
> > > > > > > > > > > Are we ready to present the list to the user list?
> > > > > > > > > > >
> > > > > > > > > > > вт, 2 июл. 2019 г. в 00:27, Denis Magda <
> > dmagda@apache.org
> > > >:
> > > > > > > > > > >
> > > > > > > > > > > > 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 <
> > > > > dpavlov@apache.org>
> > > > > > > > > > > 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 <
> > > > > av@apache.org>:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > +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 <
> > > > > > > > dmagda@apache.org>
> > > > > > > > > > > > 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
> > <
> > > > > > > > > > > > > > > alexey.goncharuk@gmail.com>
> > > > > > > > > > > > > > > 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 <
> > > > > > > > av@apache.org>:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 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
> > > > <
> > > > > > > > > > > > > > > > > alexey.goncharuk@gmail.com>
> > > > > > > > > > > > > > > > > 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 <
> > > > > > > > > > > > > > > > > > dmitry.melnichuk@nobitlost.com>:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 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)
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Best regards,
> > > > > > > > > Ivan Pavlukhin
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Best regards,
> > > > > > > > Ivan Pavlukhin
> > > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Best regards,
> > > > > > Ivan Pavlukhin
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Best Regards, Vyacheslav D.
> > > > >
> > > >
> > >
> >
>
Re: [DISCUSSION] Ignite 3.0 and to be removed list
Posted by Alexey Zinoviev <za...@gmail.com>.
Thanks for the clarification, will try to vote
чт, 25 июл. 2019 г. в 04:11, Denis Magda <dm...@gridgain.com>:
> Alexey,
>
> I've changed format on the wiki so that every community member can cast +1
> and -1 vote explaining his/her stance. This should help us to filter out
> those integrations that everyone agrees to discontinue vs. those that are
> controversial. Please, *everyone interested* share your opinion by putting
> a name and +1/-1 in these tables:
>
> - Integrations for discontinuation:
>
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-IntegrationsforDiscontinuation
> - APIs for removal:
>
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-APIsforRemoval
>
>
>
> 1. Exclude Spatial Indexes from API for removal (I don't know internal
> > issues, but is I'd like this kind of index)
>
>
> Both spatial and full-text search indexes provide limit support and not
> integrated with Ignite's memory architecture. It's better for us to remove
> them in Ignite 3.0 (that will go with a new API to be proposed soon by Alex
> Goncharuk) and rebuild from scratch in 3.1/3.2.
>
>
> > 2. Exclude Storm, Flume, Flink from Integrations for Discontinuation
> > because I've ready to try support them (or dive in this question) I think
> > no so many work to support them or move to the separate module like
> > BigDataTools Integrations
>
>
> Why don't we have them as separate Github projects that can be updated both
> by the community members and independent developers? I just don't want this
> to be a burden of the community to test and maintain it for every release.
>
> 3. Annotations based configuration of SQL - we should be careful with that,
> > I suppose it's useful feature
>
>
> Alex Goncharuk should propose a new API for 3.0 soon.
>
> 4. Ignite Messaging should be combined together with Kafka/different MQ
> > integration into one module for messaging support
>
>
> I wouldn't do this because 3rd party MQs go with their own versions that
> start conflicting over the time. For instance, we already have several
> modules for Hibernate and Spring Data integrations. To fix that, we just
> need to store integrations in separate repos and do forks if a new
> conflicting version has to be supported but there is still significant
> usage of the old one.
>
> --
> Denis Magda
>
>
> On Tue, Jul 23, 2019 at 3:16 AM Alexey Zinoviev <za...@gmail.com>
> wrote:
>
> > I have a few ideas, maybe somebody will support me
> > 1. Exclude Spatial Indexes from API for removal (I don't know internal
> > issues, but is I'd like this kind of index)
> > 2. Exclude Storm, Flume, Flink from Integrations for Discontinuation
> > because I've ready to try support them (or dive in this question) I think
> > no so many work to support them or move to the separate module like
> > BigDataTools Integrations
> > 3. Annotations based configuration of SQL - we should be careful with
> that,
> > I suppose it's useful feature
> > 4. Ignite Messaging should be combined together with Kafka/different MQ
> > integration into one module for messaging support
> >
> > What do you think guys?
> >
> > пн, 22 июл. 2019 г. в 22:51, Denis Magda <dm...@apache.org>:
> >
> > > Igniters,
> > >
> > > I did the first run through the wishlist and selected integrations and
> > APIs
> > > for discontinuation. My suggestion would be to use IEP-36
> > (Modularization)
> > > page for the final list that we'll send to the user list for feedback:
> > >
> > > - Integrations for discontinuation:
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-IntegrationsforDiscontinuation
> > > - APIs for removal:
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-APIsforRemoval
> > >
> > > Please check those lists and let us know if you have any arguments
> > against
> > > discontinuation/removal of X. Also, if you believe that something
> listed
> > in
> > > the wishlist should be added to the EIP then let's discuss that.
> > > Personally, I see the whishlist as a page with ideas while the IEP a
> > final
> > > plan for action.
> > >
> > >
> > > -
> > > Denis
> > >
> > >
> > > On Mon, Jul 22, 2019 at 12:05 AM Vyacheslav Daradur <
> daradurvs@gmail.com
> > >
> > > wrote:
> > >
> > > > I think all agreed items should be marked @Deprecated in the code
> > > > base, so we will be able to remove them transparently for the
> > > > end-users.
> > > >
> > > > On Mon, Jul 22, 2019 at 9:32 AM Павлухин Иван <vo...@gmail.com>
> > > wrote:
> > > > >
> > > > > Alex,
> > > > >
> > > > > I already added a couple of items to wishlist [1].
> > > > >
> > > > > Yes, I agree that the process should be iterative. But I am
> confused
> > > > > on what stage we are in a current interation? I suppose that Denis
> is
> > > > > going to present a list of removal candidates which we as
> developers
> > > > > agreed on. And should not we have that list already available
> > > > > somewhere as a document? Now I see an infromation scattered in this
> > > > > thread and the wishlist [1]. And it is not easy to me to realize
> > where
> > > > > we are now.
> > > > >
> > > > > [1]
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist
> > > > >
> > > > > чт, 18 июл. 2019 г. в 18:14, Alexey Goncharuk <
> > > > alexey.goncharuk@gmail.com>:
> > > > > >
> > > > > > Ivan,
> > > > > >
> > > > > > The list is not final, we can still discuss and add more points
> to
> > be
> > > > > > cleaned in 3.0. The more clear and understandable the API will
> be,
> > > the
> > > > > > better. This thread was intended to draft the removal scope for
> 3.0
> > > > and to
> > > > > > understand which portions will be definitely removed.
> > > > > >
> > > > > >
> > > > > > ср, 17 июл. 2019 г. в 15:26, Павлухин Иван <vololo100@gmail.com
> >:
> > > > > >
> > > > > > > Also, I did not quite get the point about JSR107 (JCache). From
> > > time
> > > > > > > to time I see on user-list threads where Ignite is used along
> > with
> > > > > > > Spring annotation-based cache integration. I suppose it
> requires
> > > > > > > JCache interfaces. What is crucially wrong with supporting it?
> > > > > > >
> > > > > > > ср, 17 июл. 2019 г. в 15:19, Павлухин Иван <
> vololo100@gmail.com
> > >:
> > > > > > > >
> > > > > > > > Folks,
> > > > > > > >
> > > > > > > > Sorry if I am repeating something. I checked a page [1] and
> > have
> > > > not
> > > > > > > > found several items.
> > > > > > > > 1. I thought that there was an agreement of dropping OLD
> > service
> > > > grid,
> > > > > > > > was not it?
> > > > > > > > 2. Also IndexingSpi seems to me as a candidate for removal.
> > > > > > > >
> > > > > > > > Should I add those items to the page? Or is there another
> page
> > > > > > > > containing items to be removed that we agreed on?
> > > > > > > >
> > > > > > > > [1]
> > > > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist
> > > > > > > >
> > > > > > > > ср, 17 июл. 2019 г. в 02:00, Denis Magda <dmagda@apache.org
> >:
> > > > > > > > >
> > > > > > > > > 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 <
> > > > > > > alexey.goncharuk@gmail.com>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Denis,
> > > > > > > > > >
> > > > > > > > > > Are we ready to present the list to the user list?
> > > > > > > > > >
> > > > > > > > > > вт, 2 июл. 2019 г. в 00:27, Denis Magda <
> dmagda@apache.org
> > >:
> > > > > > > > > >
> > > > > > > > > > > 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 <
> > > > dpavlov@apache.org>
> > > > > > > > > > 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 <
> > > > av@apache.org>:
> > > > > > > > > > > >
> > > > > > > > > > > > > +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 <
> > > > > > > dmagda@apache.org>
> > > > > > > > > > > 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
> <
> > > > > > > > > > > > > > alexey.goncharuk@gmail.com>
> > > > > > > > > > > > > > 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 <
> > > > > > > av@apache.org>:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 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
> > > <
> > > > > > > > > > > > > > > > alexey.goncharuk@gmail.com>
> > > > > > > > > > > > > > > > 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 <
> > > > > > > > > > > > > > > > > dmitry.melnichuk@nobitlost.com>:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 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)
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Best regards,
> > > > > > > > Ivan Pavlukhin
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Best regards,
> > > > > > > Ivan Pavlukhin
> > > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Best regards,
> > > > > Ivan Pavlukhin
> > > >
> > > >
> > > >
> > > > --
> > > > Best Regards, Vyacheslav D.
> > > >
> > >
> >
>
Re: [DISCUSSION] Ignite 3.0 and to be removed list
Posted by Denis Magda <dm...@gridgain.com>.
Alexey,
I've changed format on the wiki so that every community member can cast +1
and -1 vote explaining his/her stance. This should help us to filter out
those integrations that everyone agrees to discontinue vs. those that are
controversial. Please, *everyone interested* share your opinion by putting
a name and +1/-1 in these tables:
- Integrations for discontinuation:
https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-IntegrationsforDiscontinuation
- APIs for removal:
https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-APIsforRemoval
1. Exclude Spatial Indexes from API for removal (I don't know internal
> issues, but is I'd like this kind of index)
Both spatial and full-text search indexes provide limit support and not
integrated with Ignite's memory architecture. It's better for us to remove
them in Ignite 3.0 (that will go with a new API to be proposed soon by Alex
Goncharuk) and rebuild from scratch in 3.1/3.2.
> 2. Exclude Storm, Flume, Flink from Integrations for Discontinuation
> because I've ready to try support them (or dive in this question) I think
> no so many work to support them or move to the separate module like
> BigDataTools Integrations
Why don't we have them as separate Github projects that can be updated both
by the community members and independent developers? I just don't want this
to be a burden of the community to test and maintain it for every release.
3. Annotations based configuration of SQL - we should be careful with that,
> I suppose it's useful feature
Alex Goncharuk should propose a new API for 3.0 soon.
4. Ignite Messaging should be combined together with Kafka/different MQ
> integration into one module for messaging support
I wouldn't do this because 3rd party MQs go with their own versions that
start conflicting over the time. For instance, we already have several
modules for Hibernate and Spring Data integrations. To fix that, we just
need to store integrations in separate repos and do forks if a new
conflicting version has to be supported but there is still significant
usage of the old one.
--
Denis Magda
On Tue, Jul 23, 2019 at 3:16 AM Alexey Zinoviev <za...@gmail.com>
wrote:
> I have a few ideas, maybe somebody will support me
> 1. Exclude Spatial Indexes from API for removal (I don't know internal
> issues, but is I'd like this kind of index)
> 2. Exclude Storm, Flume, Flink from Integrations for Discontinuation
> because I've ready to try support them (or dive in this question) I think
> no so many work to support them or move to the separate module like
> BigDataTools Integrations
> 3. Annotations based configuration of SQL - we should be careful with that,
> I suppose it's useful feature
> 4. Ignite Messaging should be combined together with Kafka/different MQ
> integration into one module for messaging support
>
> What do you think guys?
>
> пн, 22 июл. 2019 г. в 22:51, Denis Magda <dm...@apache.org>:
>
> > Igniters,
> >
> > I did the first run through the wishlist and selected integrations and
> APIs
> > for discontinuation. My suggestion would be to use IEP-36
> (Modularization)
> > page for the final list that we'll send to the user list for feedback:
> >
> > - Integrations for discontinuation:
> >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-IntegrationsforDiscontinuation
> > - APIs for removal:
> >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-APIsforRemoval
> >
> > Please check those lists and let us know if you have any arguments
> against
> > discontinuation/removal of X. Also, if you believe that something listed
> in
> > the wishlist should be added to the EIP then let's discuss that.
> > Personally, I see the whishlist as a page with ideas while the IEP a
> final
> > plan for action.
> >
> >
> > -
> > Denis
> >
> >
> > On Mon, Jul 22, 2019 at 12:05 AM Vyacheslav Daradur <daradurvs@gmail.com
> >
> > wrote:
> >
> > > I think all agreed items should be marked @Deprecated in the code
> > > base, so we will be able to remove them transparently for the
> > > end-users.
> > >
> > > On Mon, Jul 22, 2019 at 9:32 AM Павлухин Иван <vo...@gmail.com>
> > wrote:
> > > >
> > > > Alex,
> > > >
> > > > I already added a couple of items to wishlist [1].
> > > >
> > > > Yes, I agree that the process should be iterative. But I am confused
> > > > on what stage we are in a current interation? I suppose that Denis is
> > > > going to present a list of removal candidates which we as developers
> > > > agreed on. And should not we have that list already available
> > > > somewhere as a document? Now I see an infromation scattered in this
> > > > thread and the wishlist [1]. And it is not easy to me to realize
> where
> > > > we are now.
> > > >
> > > > [1]
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist
> > > >
> > > > чт, 18 июл. 2019 г. в 18:14, Alexey Goncharuk <
> > > alexey.goncharuk@gmail.com>:
> > > > >
> > > > > Ivan,
> > > > >
> > > > > The list is not final, we can still discuss and add more points to
> be
> > > > > cleaned in 3.0. The more clear and understandable the API will be,
> > the
> > > > > better. This thread was intended to draft the removal scope for 3.0
> > > and to
> > > > > understand which portions will be definitely removed.
> > > > >
> > > > >
> > > > > ср, 17 июл. 2019 г. в 15:26, Павлухин Иван <vo...@gmail.com>:
> > > > >
> > > > > > Also, I did not quite get the point about JSR107 (JCache). From
> > time
> > > > > > to time I see on user-list threads where Ignite is used along
> with
> > > > > > Spring annotation-based cache integration. I suppose it requires
> > > > > > JCache interfaces. What is crucially wrong with supporting it?
> > > > > >
> > > > > > ср, 17 июл. 2019 г. в 15:19, Павлухин Иван <vololo100@gmail.com
> >:
> > > > > > >
> > > > > > > Folks,
> > > > > > >
> > > > > > > Sorry if I am repeating something. I checked a page [1] and
> have
> > > not
> > > > > > > found several items.
> > > > > > > 1. I thought that there was an agreement of dropping OLD
> service
> > > grid,
> > > > > > > was not it?
> > > > > > > 2. Also IndexingSpi seems to me as a candidate for removal.
> > > > > > >
> > > > > > > Should I add those items to the page? Or is there another page
> > > > > > > containing items to be removed that we agreed on?
> > > > > > >
> > > > > > > [1]
> > > > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist
> > > > > > >
> > > > > > > ср, 17 июл. 2019 г. в 02:00, Denis Magda <dm...@apache.org>:
> > > > > > > >
> > > > > > > > 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 <
> > > > > > alexey.goncharuk@gmail.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Denis,
> > > > > > > > >
> > > > > > > > > Are we ready to present the list to the user list?
> > > > > > > > >
> > > > > > > > > вт, 2 июл. 2019 г. в 00:27, Denis Magda <dmagda@apache.org
> >:
> > > > > > > > >
> > > > > > > > > > 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 <
> > > dpavlov@apache.org>
> > > > > > > > > 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 <
> > > av@apache.org>:
> > > > > > > > > > >
> > > > > > > > > > > > +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 <
> > > > > > dmagda@apache.org>
> > > > > > > > > > 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 <
> > > > > > > > > > > > > alexey.goncharuk@gmail.com>
> > > > > > > > > > > > > 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 <
> > > > > > av@apache.org>:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 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
> > <
> > > > > > > > > > > > > > > alexey.goncharuk@gmail.com>
> > > > > > > > > > > > > > > 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 <
> > > > > > > > > > > > > > > > dmitry.melnichuk@nobitlost.com>:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 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)
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Best regards,
> > > > > > > Ivan Pavlukhin
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Best regards,
> > > > > > Ivan Pavlukhin
> > > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Best regards,
> > > > Ivan Pavlukhin
> > >
> > >
> > >
> > > --
> > > Best Regards, Vyacheslav D.
> > >
> >
>
Re: [DISCUSSION] Ignite 3.0 and to be removed list
Posted by Alexey Zinoviev <za...@gmail.com>.
I have a few ideas, maybe somebody will support me
1. Exclude Spatial Indexes from API for removal (I don't know internal
issues, but is I'd like this kind of index)
2. Exclude Storm, Flume, Flink from Integrations for Discontinuation
because I've ready to try support them (or dive in this question) I think
no so many work to support them or move to the separate module like
BigDataTools Integrations
3. Annotations based configuration of SQL - we should be careful with that,
I suppose it's useful feature
4. Ignite Messaging should be combined together with Kafka/different MQ
integration into one module for messaging support
What do you think guys?
пн, 22 июл. 2019 г. в 22:51, Denis Magda <dm...@apache.org>:
> Igniters,
>
> I did the first run through the wishlist and selected integrations and APIs
> for discontinuation. My suggestion would be to use IEP-36 (Modularization)
> page for the final list that we'll send to the user list for feedback:
>
> - Integrations for discontinuation:
>
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-IntegrationsforDiscontinuation
> - APIs for removal:
>
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-APIsforRemoval
>
> Please check those lists and let us know if you have any arguments against
> discontinuation/removal of X. Also, if you believe that something listed in
> the wishlist should be added to the EIP then let's discuss that.
> Personally, I see the whishlist as a page with ideas while the IEP a final
> plan for action.
>
>
> -
> Denis
>
>
> On Mon, Jul 22, 2019 at 12:05 AM Vyacheslav Daradur <da...@gmail.com>
> wrote:
>
> > I think all agreed items should be marked @Deprecated in the code
> > base, so we will be able to remove them transparently for the
> > end-users.
> >
> > On Mon, Jul 22, 2019 at 9:32 AM Павлухин Иван <vo...@gmail.com>
> wrote:
> > >
> > > Alex,
> > >
> > > I already added a couple of items to wishlist [1].
> > >
> > > Yes, I agree that the process should be iterative. But I am confused
> > > on what stage we are in a current interation? I suppose that Denis is
> > > going to present a list of removal candidates which we as developers
> > > agreed on. And should not we have that list already available
> > > somewhere as a document? Now I see an infromation scattered in this
> > > thread and the wishlist [1]. And it is not easy to me to realize where
> > > we are now.
> > >
> > > [1]
> >
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist
> > >
> > > чт, 18 июл. 2019 г. в 18:14, Alexey Goncharuk <
> > alexey.goncharuk@gmail.com>:
> > > >
> > > > Ivan,
> > > >
> > > > The list is not final, we can still discuss and add more points to be
> > > > cleaned in 3.0. The more clear and understandable the API will be,
> the
> > > > better. This thread was intended to draft the removal scope for 3.0
> > and to
> > > > understand which portions will be definitely removed.
> > > >
> > > >
> > > > ср, 17 июл. 2019 г. в 15:26, Павлухин Иван <vo...@gmail.com>:
> > > >
> > > > > Also, I did not quite get the point about JSR107 (JCache). From
> time
> > > > > to time I see on user-list threads where Ignite is used along with
> > > > > Spring annotation-based cache integration. I suppose it requires
> > > > > JCache interfaces. What is crucially wrong with supporting it?
> > > > >
> > > > > ср, 17 июл. 2019 г. в 15:19, Павлухин Иван <vo...@gmail.com>:
> > > > > >
> > > > > > Folks,
> > > > > >
> > > > > > Sorry if I am repeating something. I checked a page [1] and have
> > not
> > > > > > found several items.
> > > > > > 1. I thought that there was an agreement of dropping OLD service
> > grid,
> > > > > > was not it?
> > > > > > 2. Also IndexingSpi seems to me as a candidate for removal.
> > > > > >
> > > > > > Should I add those items to the page? Or is there another page
> > > > > > containing items to be removed that we agreed on?
> > > > > >
> > > > > > [1]
> > > > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist
> > > > > >
> > > > > > ср, 17 июл. 2019 г. в 02:00, Denis Magda <dm...@apache.org>:
> > > > > > >
> > > > > > > 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 <
> > > > > alexey.goncharuk@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Denis,
> > > > > > > >
> > > > > > > > Are we ready to present the list to the user list?
> > > > > > > >
> > > > > > > > вт, 2 июл. 2019 г. в 00:27, Denis Magda <dm...@apache.org>:
> > > > > > > >
> > > > > > > > > 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 <
> > dpavlov@apache.org>
> > > > > > > > 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 <
> > av@apache.org>:
> > > > > > > > > >
> > > > > > > > > > > +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 <
> > > > > dmagda@apache.org>
> > > > > > > > > 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 <
> > > > > > > > > > > > alexey.goncharuk@gmail.com>
> > > > > > > > > > > > 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 <
> > > > > av@apache.org>:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > 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
> <
> > > > > > > > > > > > > > alexey.goncharuk@gmail.com>
> > > > > > > > > > > > > > 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 <
> > > > > > > > > > > > > > > dmitry.melnichuk@nobitlost.com>:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 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)
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Best regards,
> > > > > > Ivan Pavlukhin
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Best regards,
> > > > > Ivan Pavlukhin
> > > > >
> > >
> > >
> > >
> > > --
> > > Best regards,
> > > Ivan Pavlukhin
> >
> >
> >
> > --
> > Best Regards, Vyacheslav D.
> >
>
Re: [DISCUSSION] Ignite 3.0 and to be removed list
Posted by Denis Magda <dm...@apache.org>.
Igniters,
I did the first run through the wishlist and selected integrations and APIs
for discontinuation. My suggestion would be to use IEP-36 (Modularization)
page for the final list that we'll send to the user list for feedback:
- Integrations for discontinuation:
https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-IntegrationsforDiscontinuation
- APIs for removal:
https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-APIsforRemoval
Please check those lists and let us know if you have any arguments against
discontinuation/removal of X. Also, if you believe that something listed in
the wishlist should be added to the EIP then let's discuss that.
Personally, I see the whishlist as a page with ideas while the IEP a final
plan for action.
-
Denis
On Mon, Jul 22, 2019 at 12:05 AM Vyacheslav Daradur <da...@gmail.com>
wrote:
> I think all agreed items should be marked @Deprecated in the code
> base, so we will be able to remove them transparently for the
> end-users.
>
> On Mon, Jul 22, 2019 at 9:32 AM Павлухин Иван <vo...@gmail.com> wrote:
> >
> > Alex,
> >
> > I already added a couple of items to wishlist [1].
> >
> > Yes, I agree that the process should be iterative. But I am confused
> > on what stage we are in a current interation? I suppose that Denis is
> > going to present a list of removal candidates which we as developers
> > agreed on. And should not we have that list already available
> > somewhere as a document? Now I see an infromation scattered in this
> > thread and the wishlist [1]. And it is not easy to me to realize where
> > we are now.
> >
> > [1]
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist
> >
> > чт, 18 июл. 2019 г. в 18:14, Alexey Goncharuk <
> alexey.goncharuk@gmail.com>:
> > >
> > > Ivan,
> > >
> > > The list is not final, we can still discuss and add more points to be
> > > cleaned in 3.0. The more clear and understandable the API will be, the
> > > better. This thread was intended to draft the removal scope for 3.0
> and to
> > > understand which portions will be definitely removed.
> > >
> > >
> > > ср, 17 июл. 2019 г. в 15:26, Павлухин Иван <vo...@gmail.com>:
> > >
> > > > Also, I did not quite get the point about JSR107 (JCache). From time
> > > > to time I see on user-list threads where Ignite is used along with
> > > > Spring annotation-based cache integration. I suppose it requires
> > > > JCache interfaces. What is crucially wrong with supporting it?
> > > >
> > > > ср, 17 июл. 2019 г. в 15:19, Павлухин Иван <vo...@gmail.com>:
> > > > >
> > > > > Folks,
> > > > >
> > > > > Sorry if I am repeating something. I checked a page [1] and have
> not
> > > > > found several items.
> > > > > 1. I thought that there was an agreement of dropping OLD service
> grid,
> > > > > was not it?
> > > > > 2. Also IndexingSpi seems to me as a candidate for removal.
> > > > >
> > > > > Should I add those items to the page? Or is there another page
> > > > > containing items to be removed that we agreed on?
> > > > >
> > > > > [1]
> > > >
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist
> > > > >
> > > > > ср, 17 июл. 2019 г. в 02:00, Denis Magda <dm...@apache.org>:
> > > > > >
> > > > > > 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 <
> > > > alexey.goncharuk@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Denis,
> > > > > > >
> > > > > > > Are we ready to present the list to the user list?
> > > > > > >
> > > > > > > вт, 2 июл. 2019 г. в 00:27, Denis Magda <dm...@apache.org>:
> > > > > > >
> > > > > > > > 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 <
> dpavlov@apache.org>
> > > > > > > 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 <
> av@apache.org>:
> > > > > > > > >
> > > > > > > > > > +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 <
> > > > dmagda@apache.org>
> > > > > > > > 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 <
> > > > > > > > > > > alexey.goncharuk@gmail.com>
> > > > > > > > > > > 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 <
> > > > av@apache.org>:
> > > > > > > > > > > >
> > > > > > > > > > > > > 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 <
> > > > > > > > > > > > > alexey.goncharuk@gmail.com>
> > > > > > > > > > > > > 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 <
> > > > > > > > > > > > > > dmitry.melnichuk@nobitlost.com>:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 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)
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Best regards,
> > > > > Ivan Pavlukhin
> > > >
> > > >
> > > >
> > > > --
> > > > Best regards,
> > > > Ivan Pavlukhin
> > > >
> >
> >
> >
> > --
> > Best regards,
> > Ivan Pavlukhin
>
>
>
> --
> Best Regards, Vyacheslav D.
>
Re: [DISCUSSION] Ignite 3.0 and to be removed list
Posted by Vyacheslav Daradur <da...@gmail.com>.
I think all agreed items should be marked @Deprecated in the code
base, so we will be able to remove them transparently for the
end-users.
On Mon, Jul 22, 2019 at 9:32 AM Павлухин Иван <vo...@gmail.com> wrote:
>
> Alex,
>
> I already added a couple of items to wishlist [1].
>
> Yes, I agree that the process should be iterative. But I am confused
> on what stage we are in a current interation? I suppose that Denis is
> going to present a list of removal candidates which we as developers
> agreed on. And should not we have that list already available
> somewhere as a document? Now I see an infromation scattered in this
> thread and the wishlist [1]. And it is not easy to me to realize where
> we are now.
>
> [1] https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist
>
> чт, 18 июл. 2019 г. в 18:14, Alexey Goncharuk <al...@gmail.com>:
> >
> > Ivan,
> >
> > The list is not final, we can still discuss and add more points to be
> > cleaned in 3.0. The more clear and understandable the API will be, the
> > better. This thread was intended to draft the removal scope for 3.0 and to
> > understand which portions will be definitely removed.
> >
> >
> > ср, 17 июл. 2019 г. в 15:26, Павлухин Иван <vo...@gmail.com>:
> >
> > > Also, I did not quite get the point about JSR107 (JCache). From time
> > > to time I see on user-list threads where Ignite is used along with
> > > Spring annotation-based cache integration. I suppose it requires
> > > JCache interfaces. What is crucially wrong with supporting it?
> > >
> > > ср, 17 июл. 2019 г. в 15:19, Павлухин Иван <vo...@gmail.com>:
> > > >
> > > > Folks,
> > > >
> > > > Sorry if I am repeating something. I checked a page [1] and have not
> > > > found several items.
> > > > 1. I thought that there was an agreement of dropping OLD service grid,
> > > > was not it?
> > > > 2. Also IndexingSpi seems to me as a candidate for removal.
> > > >
> > > > Should I add those items to the page? Or is there another page
> > > > containing items to be removed that we agreed on?
> > > >
> > > > [1]
> > > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist
> > > >
> > > > ср, 17 июл. 2019 г. в 02:00, Denis Magda <dm...@apache.org>:
> > > > >
> > > > > 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 <
> > > alexey.goncharuk@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Denis,
> > > > > >
> > > > > > Are we ready to present the list to the user list?
> > > > > >
> > > > > > вт, 2 июл. 2019 г. в 00:27, Denis Magda <dm...@apache.org>:
> > > > > >
> > > > > > > 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 <dp...@apache.org>
> > > > > > 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 <av...@apache.org>:
> > > > > > > >
> > > > > > > > > +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 <
> > > dmagda@apache.org>
> > > > > > > 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 <
> > > > > > > > > > alexey.goncharuk@gmail.com>
> > > > > > > > > > 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 <
> > > av@apache.org>:
> > > > > > > > > > >
> > > > > > > > > > > > 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 <
> > > > > > > > > > > > alexey.goncharuk@gmail.com>
> > > > > > > > > > > > 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 <
> > > > > > > > > > > > > dmitry.melnichuk@nobitlost.com>:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > 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)
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Best regards,
> > > > Ivan Pavlukhin
> > >
> > >
> > >
> > > --
> > > Best regards,
> > > Ivan Pavlukhin
> > >
>
>
>
> --
> Best regards,
> Ivan Pavlukhin
--
Best Regards, Vyacheslav D.
Re: [DISCUSSION] Ignite 3.0 and to be removed list
Posted by Павлухин Иван <vo...@gmail.com>.
Alex,
I already added a couple of items to wishlist [1].
Yes, I agree that the process should be iterative. But I am confused
on what stage we are in a current interation? I suppose that Denis is
going to present a list of removal candidates which we as developers
agreed on. And should not we have that list already available
somewhere as a document? Now I see an infromation scattered in this
thread and the wishlist [1]. And it is not easy to me to realize where
we are now.
[1] https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist
чт, 18 июл. 2019 г. в 18:14, Alexey Goncharuk <al...@gmail.com>:
>
> Ivan,
>
> The list is not final, we can still discuss and add more points to be
> cleaned in 3.0. The more clear and understandable the API will be, the
> better. This thread was intended to draft the removal scope for 3.0 and to
> understand which portions will be definitely removed.
>
>
> ср, 17 июл. 2019 г. в 15:26, Павлухин Иван <vo...@gmail.com>:
>
> > Also, I did not quite get the point about JSR107 (JCache). From time
> > to time I see on user-list threads where Ignite is used along with
> > Spring annotation-based cache integration. I suppose it requires
> > JCache interfaces. What is crucially wrong with supporting it?
> >
> > ср, 17 июл. 2019 г. в 15:19, Павлухин Иван <vo...@gmail.com>:
> > >
> > > Folks,
> > >
> > > Sorry if I am repeating something. I checked a page [1] and have not
> > > found several items.
> > > 1. I thought that there was an agreement of dropping OLD service grid,
> > > was not it?
> > > 2. Also IndexingSpi seems to me as a candidate for removal.
> > >
> > > Should I add those items to the page? Or is there another page
> > > containing items to be removed that we agreed on?
> > >
> > > [1]
> > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist
> > >
> > > ср, 17 июл. 2019 г. в 02:00, Denis Magda <dm...@apache.org>:
> > > >
> > > > 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 <
> > alexey.goncharuk@gmail.com>
> > > > wrote:
> > > >
> > > > > Denis,
> > > > >
> > > > > Are we ready to present the list to the user list?
> > > > >
> > > > > вт, 2 июл. 2019 г. в 00:27, Denis Magda <dm...@apache.org>:
> > > > >
> > > > > > 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 <dp...@apache.org>
> > > > > 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 <av...@apache.org>:
> > > > > > >
> > > > > > > > +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 <
> > dmagda@apache.org>
> > > > > > 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 <
> > > > > > > > > alexey.goncharuk@gmail.com>
> > > > > > > > > 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 <
> > av@apache.org>:
> > > > > > > > > >
> > > > > > > > > > > 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 <
> > > > > > > > > > > alexey.goncharuk@gmail.com>
> > > > > > > > > > > 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 <
> > > > > > > > > > > > dmitry.melnichuk@nobitlost.com>:
> > > > > > > > > > > >
> > > > > > > > > > > > > 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)
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> > >
> > >
> > > --
> > > Best regards,
> > > Ivan Pavlukhin
> >
> >
> >
> > --
> > Best regards,
> > Ivan Pavlukhin
> >
--
Best regards,
Ivan Pavlukhin
Re: [DISCUSSION] Ignite 3.0 and to be removed list
Posted by Alexey Goncharuk <al...@gmail.com>.
Ivan,
The list is not final, we can still discuss and add more points to be
cleaned in 3.0. The more clear and understandable the API will be, the
better. This thread was intended to draft the removal scope for 3.0 and to
understand which portions will be definitely removed.
ср, 17 июл. 2019 г. в 15:26, Павлухин Иван <vo...@gmail.com>:
> Also, I did not quite get the point about JSR107 (JCache). From time
> to time I see on user-list threads where Ignite is used along with
> Spring annotation-based cache integration. I suppose it requires
> JCache interfaces. What is crucially wrong with supporting it?
>
> ср, 17 июл. 2019 г. в 15:19, Павлухин Иван <vo...@gmail.com>:
> >
> > Folks,
> >
> > Sorry if I am repeating something. I checked a page [1] and have not
> > found several items.
> > 1. I thought that there was an agreement of dropping OLD service grid,
> > was not it?
> > 2. Also IndexingSpi seems to me as a candidate for removal.
> >
> > Should I add those items to the page? Or is there another page
> > containing items to be removed that we agreed on?
> >
> > [1]
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist
> >
> > ср, 17 июл. 2019 г. в 02:00, Denis Magda <dm...@apache.org>:
> > >
> > > 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 <
> alexey.goncharuk@gmail.com>
> > > wrote:
> > >
> > > > Denis,
> > > >
> > > > Are we ready to present the list to the user list?
> > > >
> > > > вт, 2 июл. 2019 г. в 00:27, Denis Magda <dm...@apache.org>:
> > > >
> > > > > 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 <dp...@apache.org>
> > > > 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 <av...@apache.org>:
> > > > > >
> > > > > > > +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 <
> dmagda@apache.org>
> > > > > 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 <
> > > > > > > > alexey.goncharuk@gmail.com>
> > > > > > > > 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 <
> av@apache.org>:
> > > > > > > > >
> > > > > > > > > > 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 <
> > > > > > > > > > alexey.goncharuk@gmail.com>
> > > > > > > > > > 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 <
> > > > > > > > > > > dmitry.melnichuk@nobitlost.com>:
> > > > > > > > > > >
> > > > > > > > > > > > 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)
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> >
> >
> >
> > --
> > Best regards,
> > Ivan Pavlukhin
>
>
>
> --
> Best regards,
> Ivan Pavlukhin
>
Re: [DISCUSSION] Ignite 3.0 and to be removed list
Posted by Dmitriy Pavlov <dp...@apache.org>.
JSR107 point - it is standard, it is always easy to refer to something user
may already know.
BTW we have 1.0 in Ignite dependency, 1.1.1 recently released, maybe we
should upgrade in 3.0.
See also:
https://mvnrepository.com/artifact/javax.cache/cache-api/1.1.1
ср, 17 июл. 2019 г. в 15:51, Vyacheslav Daradur <da...@gmail.com>:
> Ivan,
>
> * About Service Grid:
> Yes, we discussed that old service grid implementation
> (GridServiceProcessor) should be removed in 3.0, now it is marked as
> obsolete.
> This was in the list, maybe it was lost during formatting.
>
> Also, a class `ServiceConfiguration` should be moved to common package
> of configurations: 'org.apache.ignite.configuration' it will bring to
> change of API.
>
> * About JSR107:
> I thought that JSR107 compliance is one of the advantages of Ignite,
> at least in In-Memory mode.
> I'm not sure why we should drop it.
>
> On Wed, Jul 17, 2019 at 3:26 PM Павлухин Иван <vo...@gmail.com> wrote:
> >
> > Also, I did not quite get the point about JSR107 (JCache). From time
> > to time I see on user-list threads where Ignite is used along with
> > Spring annotation-based cache integration. I suppose it requires
> > JCache interfaces. What is crucially wrong with supporting it?
> >
> > ср, 17 июл. 2019 г. в 15:19, Павлухин Иван <vo...@gmail.com>:
> > >
> > > Folks,
> > >
> > > Sorry if I am repeating something. I checked a page [1] and have not
> > > found several items.
> > > 1. I thought that there was an agreement of dropping OLD service grid,
> > > was not it?
> > > 2. Also IndexingSpi seems to me as a candidate for removal.
> > >
> > > Should I add those items to the page? Or is there another page
> > > containing items to be removed that we agreed on?
> > >
> > > [1]
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist
> > >
> > > ср, 17 июл. 2019 г. в 02:00, Denis Magda <dm...@apache.org>:
> > > >
> > > > 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 <
> alexey.goncharuk@gmail.com>
> > > > wrote:
> > > >
> > > > > Denis,
> > > > >
> > > > > Are we ready to present the list to the user list?
> > > > >
> > > > > вт, 2 июл. 2019 г. в 00:27, Denis Magda <dm...@apache.org>:
> > > > >
> > > > > > 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 <
> dpavlov@apache.org>
> > > > > 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 <av...@apache.org>:
> > > > > > >
> > > > > > > > +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 <
> dmagda@apache.org>
> > > > > > 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 <
> > > > > > > > > alexey.goncharuk@gmail.com>
> > > > > > > > > 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 <
> av@apache.org>:
> > > > > > > > > >
> > > > > > > > > > > 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 <
> > > > > > > > > > > alexey.goncharuk@gmail.com>
> > > > > > > > > > > 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 <
> > > > > > > > > > > > dmitry.melnichuk@nobitlost.com>:
> > > > > > > > > > > >
> > > > > > > > > > > > > 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)
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> > >
> > >
> > > --
> > > Best regards,
> > > Ivan Pavlukhin
> >
> >
> >
> > --
> > Best regards,
> > Ivan Pavlukhin
>
>
>
> --
> Best Regards, Vyacheslav D.
>
Re: [DISCUSSION] Ignite 3.0 and to be removed list
Posted by Vyacheslav Daradur <da...@gmail.com>.
Ivan,
* About Service Grid:
Yes, we discussed that old service grid implementation
(GridServiceProcessor) should be removed in 3.0, now it is marked as
obsolete.
This was in the list, maybe it was lost during formatting.
Also, a class `ServiceConfiguration` should be moved to common package
of configurations: 'org.apache.ignite.configuration' it will bring to
change of API.
* About JSR107:
I thought that JSR107 compliance is one of the advantages of Ignite,
at least in In-Memory mode.
I'm not sure why we should drop it.
On Wed, Jul 17, 2019 at 3:26 PM Павлухин Иван <vo...@gmail.com> wrote:
>
> Also, I did not quite get the point about JSR107 (JCache). From time
> to time I see on user-list threads where Ignite is used along with
> Spring annotation-based cache integration. I suppose it requires
> JCache interfaces. What is crucially wrong with supporting it?
>
> ср, 17 июл. 2019 г. в 15:19, Павлухин Иван <vo...@gmail.com>:
> >
> > Folks,
> >
> > Sorry if I am repeating something. I checked a page [1] and have not
> > found several items.
> > 1. I thought that there was an agreement of dropping OLD service grid,
> > was not it?
> > 2. Also IndexingSpi seems to me as a candidate for removal.
> >
> > Should I add those items to the page? Or is there another page
> > containing items to be removed that we agreed on?
> >
> > [1] https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist
> >
> > ср, 17 июл. 2019 г. в 02:00, Denis Magda <dm...@apache.org>:
> > >
> > > 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 <al...@gmail.com>
> > > wrote:
> > >
> > > > Denis,
> > > >
> > > > Are we ready to present the list to the user list?
> > > >
> > > > вт, 2 июл. 2019 г. в 00:27, Denis Magda <dm...@apache.org>:
> > > >
> > > > > 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 <dp...@apache.org>
> > > > 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 <av...@apache.org>:
> > > > > >
> > > > > > > +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 <dm...@apache.org>
> > > > > 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 <
> > > > > > > > alexey.goncharuk@gmail.com>
> > > > > > > > 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 <av...@apache.org>:
> > > > > > > > >
> > > > > > > > > > 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 <
> > > > > > > > > > alexey.goncharuk@gmail.com>
> > > > > > > > > > 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 <
> > > > > > > > > > > dmitry.melnichuk@nobitlost.com>:
> > > > > > > > > > >
> > > > > > > > > > > > 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)
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> >
> >
> >
> > --
> > Best regards,
> > Ivan Pavlukhin
>
>
>
> --
> Best regards,
> Ivan Pavlukhin
--
Best Regards, Vyacheslav D.
Re: [DISCUSSION] Ignite 3.0 and to be removed list
Posted by Павлухин Иван <vo...@gmail.com>.
Also, I did not quite get the point about JSR107 (JCache). From time
to time I see on user-list threads where Ignite is used along with
Spring annotation-based cache integration. I suppose it requires
JCache interfaces. What is crucially wrong with supporting it?
ср, 17 июл. 2019 г. в 15:19, Павлухин Иван <vo...@gmail.com>:
>
> Folks,
>
> Sorry if I am repeating something. I checked a page [1] and have not
> found several items.
> 1. I thought that there was an agreement of dropping OLD service grid,
> was not it?
> 2. Also IndexingSpi seems to me as a candidate for removal.
>
> Should I add those items to the page? Or is there another page
> containing items to be removed that we agreed on?
>
> [1] https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist
>
> ср, 17 июл. 2019 г. в 02:00, Denis Magda <dm...@apache.org>:
> >
> > 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 <al...@gmail.com>
> > wrote:
> >
> > > Denis,
> > >
> > > Are we ready to present the list to the user list?
> > >
> > > вт, 2 июл. 2019 г. в 00:27, Denis Magda <dm...@apache.org>:
> > >
> > > > 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 <dp...@apache.org>
> > > 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 <av...@apache.org>:
> > > > >
> > > > > > +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 <dm...@apache.org>
> > > > 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 <
> > > > > > > alexey.goncharuk@gmail.com>
> > > > > > > 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 <av...@apache.org>:
> > > > > > > >
> > > > > > > > > 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 <
> > > > > > > > > alexey.goncharuk@gmail.com>
> > > > > > > > > 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 <
> > > > > > > > > > dmitry.melnichuk@nobitlost.com>:
> > > > > > > > > >
> > > > > > > > > > > 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)
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
>
>
>
> --
> Best regards,
> Ivan Pavlukhin
--
Best regards,
Ivan Pavlukhin
Re: [DISCUSSION] Ignite 3.0 and to be removed list
Posted by Павлухин Иван <vo...@gmail.com>.
Folks,
Sorry if I am repeating something. I checked a page [1] and have not
found several items.
1. I thought that there was an agreement of dropping OLD service grid,
was not it?
2. Also IndexingSpi seems to me as a candidate for removal.
Should I add those items to the page? Or is there another page
containing items to be removed that we agreed on?
[1] https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist
ср, 17 июл. 2019 г. в 02:00, Denis Magda <dm...@apache.org>:
>
> 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 <al...@gmail.com>
> wrote:
>
> > Denis,
> >
> > Are we ready to present the list to the user list?
> >
> > вт, 2 июл. 2019 г. в 00:27, Denis Magda <dm...@apache.org>:
> >
> > > 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 <dp...@apache.org>
> > 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 <av...@apache.org>:
> > > >
> > > > > +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 <dm...@apache.org>
> > > 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 <
> > > > > > alexey.goncharuk@gmail.com>
> > > > > > 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 <av...@apache.org>:
> > > > > > >
> > > > > > > > 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 <
> > > > > > > > alexey.goncharuk@gmail.com>
> > > > > > > > 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 <
> > > > > > > > > dmitry.melnichuk@nobitlost.com>:
> > > > > > > > >
> > > > > > > > > > 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)
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
--
Best regards,
Ivan Pavlukhin
Re: [DISCUSSION] Ignite 3.0 and to be removed list
Posted by Denis Magda <dm...@apache.org>.
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 <al...@gmail.com>
wrote:
> Denis,
>
> Are we ready to present the list to the user list?
>
> вт, 2 июл. 2019 г. в 00:27, Denis Magda <dm...@apache.org>:
>
> > 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 <dp...@apache.org>
> 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 <av...@apache.org>:
> > >
> > > > +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 <dm...@apache.org>
> > 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 <
> > > > > alexey.goncharuk@gmail.com>
> > > > > 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 <av...@apache.org>:
> > > > > >
> > > > > > > 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 <
> > > > > > > alexey.goncharuk@gmail.com>
> > > > > > > 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 <
> > > > > > > > dmitry.melnichuk@nobitlost.com>:
> > > > > > > >
> > > > > > > > > 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)
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: [DISCUSSION] Ignite 3.0 and to be removed list
Posted by Alexey Goncharuk <al...@gmail.com>.
Denis,
Are we ready to present the list to the user list?
вт, 2 июл. 2019 г. в 00:27, Denis Magda <dm...@apache.org>:
> 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 <dp...@apache.org> 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 <av...@apache.org>:
> >
> > > +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 <dm...@apache.org>
> 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 <
> > > > alexey.goncharuk@gmail.com>
> > > > 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 <av...@apache.org>:
> > > > >
> > > > > > 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 <
> > > > > > alexey.goncharuk@gmail.com>
> > > > > > 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 <
> > > > > > > dmitry.melnichuk@nobitlost.com>:
> > > > > > >
> > > > > > > > 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)
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: [DISCUSSION] Ignite 3.0 and to be removed list
Posted by Denis Magda <dm...@apache.org>.
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 <dp...@apache.org> 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 <av...@apache.org>:
>
> > +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 <dm...@apache.org> 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 <
> > > alexey.goncharuk@gmail.com>
> > > 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 <av...@apache.org>:
> > > >
> > > > > 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 <
> > > > > alexey.goncharuk@gmail.com>
> > > > > 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 <
> > > > > > dmitry.melnichuk@nobitlost.com>:
> > > > > >
> > > > > > > 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)
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: [DISCUSSION] Ignite 3.0 and to be removed list
Posted by Dmitriy Pavlov <dp...@apache.org>.
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 <av...@apache.org>:
> +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 <dm...@apache.org> 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 <
> > alexey.goncharuk@gmail.com>
> > 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 <av...@apache.org>:
> > >
> > > > 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 <
> > > > alexey.goncharuk@gmail.com>
> > > > 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 <
> > > > > dmitry.melnichuk@nobitlost.com>:
> > > > >
> > > > > > 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)
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: [DISCUSSION] Ignite 3.0 and to be removed list
Posted by Anton Vinogradov <av...@apache.org>.
+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 <dm...@apache.org> 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 <
> alexey.goncharuk@gmail.com>
> 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 <av...@apache.org>:
> >
> > > 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 <
> > > alexey.goncharuk@gmail.com>
> > > 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 <
> > > > dmitry.melnichuk@nobitlost.com>:
> > > >
> > > > > 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)
> > > > >
> > > >
> > >
> >
>
Re: [DISCUSSION] Ignite 3.0 and to be removed list
Posted by Denis Magda <dm...@apache.org>.
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 <al...@gmail.com>
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 <av...@apache.org>:
>
> > 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 <
> > alexey.goncharuk@gmail.com>
> > 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 <
> > > dmitry.melnichuk@nobitlost.com>:
> > >
> > > > 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)
> > > >
> > >
> >
>
Re: [DISCUSSION] Ignite 3.0 and to be removed list
Posted by Alexey Goncharuk <al...@gmail.com>.
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 <av...@apache.org>:
> 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 <
> alexey.goncharuk@gmail.com>
> 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 <
> > dmitry.melnichuk@nobitlost.com>:
> >
> > > 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)
> > >
> >
>
Re: [DISCUSSION] Ignite 3.0 and to be removed list
Posted by Anton Vinogradov <av...@apache.org>.
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 <al...@gmail.com>
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 <
> dmitry.melnichuk@nobitlost.com>:
>
> > 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)
> >
>
Re: [DISCUSSION] Ignite 3.0 and to be removed list
Posted by Alexey Goncharuk <al...@gmail.com>.
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 <
dmitry.melnichuk@nobitlost.com>:
> 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)
>
Re: [DISCUSSION] Ignite 3.0 and to be removed list
Posted by Dmitry Melnichuk <dm...@nobitlost.com>.
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)
Re: [DISCUSSION] Ignite 3.0 and to be removed list
Posted by Dmitriy Pavlov <dp...@apache.org>.
Denis, here is the link:
https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist
вт, 18 июн. 2019 г. в 21:28, Denis Magda <dm...@apache.org>:
> 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 <ag...@apache.org>
> 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
> >
>
Re: [DISCUSSION] Ignite 3.0 and to be removed list
Posted by Roman Shtykh <rs...@yahoo.com.INVALID>.
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 <il...@gmail.com> 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 <dm...@apache.org>:
> 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 <ag...@apache.org>
> 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
> >
>
Re: [DISCUSSION] Ignite 3.0 and to be removed list
Posted by Ilya Kasnacheev <il...@gmail.com>.
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 <dm...@apache.org>:
> 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 <ag...@apache.org>
> 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
> >
>
Re: [DISCUSSION] Ignite 3.0 and to be removed list
Posted by Denis Magda <dm...@apache.org>.
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 <ag...@apache.org>
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
>
Re: [DISCUSSION] Ignite 3.0 and to be removed list
Posted by Anton Vinogradov <av...@apache.org>.
>> * Twitter module
Every extension/adapter/etc module should be checked to be useful.
My wish is to get rid of all lesser-used features, to make AI as small as
possible.
It's time to clean-up legacy :)
BTW, do we really need TCK support?
On Mon, Jun 17, 2019 at 4:05 PM Andrey Mashenkov <an...@gmail.com>
wrote:
> Alexey,
>
> * SqlQuery (not SqlFieldsQuery)
> * Twitter module
>
> On Mon, Jun 17, 2019 at 3:52 PM Alexey Goncharuk <
> alexey.goncharuk@gmail.com>
> wrote:
>
> > Nikolay,
> >
> > Local caches and scalar are already in the list :) Added the outdated
> > metrics point.
> >
> > пн, 17 июн. 2019 г. в 15:32, Nikolay Izhikov <ni...@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
>
Re: [DISCUSSION] Ignite 3.0 and to be removed list
Posted by Andrey Mashenkov <an...@gmail.com>.
Alexey,
* SqlQuery (not SqlFieldsQuery)
* Twitter module
On Mon, Jun 17, 2019 at 3:52 PM Alexey Goncharuk <al...@gmail.com>
wrote:
> Nikolay,
>
> Local caches and scalar are already in the list :) Added the outdated
> metrics point.
>
> пн, 17 июн. 2019 г. в 15:32, Nikolay Izhikov <ni...@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
Re: [DISCUSSION] Ignite 3.0 and to be removed list
Posted by Dmitriy Pavlov <dp...@apache.org>.
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 <dp...@apache.org>:
> 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, Павлухин Иван <vo...@gmail.com>:
>
>> 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 <andrey.mashenkov@gmail.com
>> >:
>> >
>> > 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 <pl...@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 <pt...@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
>>
>>
>>
>> --
>> Best regards,
>> Ivan Pavlukhin
>>
>
Re: [DISCUSSION] Ignite 3.0 and to be removed list
Posted by Dmitriy Pavlov <dp...@apache.org>.
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, Павлухин Иван <vo...@gmail.com>:
> 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 <andrey.mashenkov@gmail.com
> >:
> >
> > 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 <pl...@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 <pt...@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 <is...@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
>
>
>
> --
> Best regards,
> Ivan Pavlukhin
>
Re: [DISCUSSION] Ignite 3.0 and to be removed list
Posted by Павлухин Иван <vo...@gmail.com>.
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 <an...@gmail.com>:
>
> 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 <pl...@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 <pt...@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 <is...@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 <jo...@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 <dp...@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
--
Best regards,
Ivan Pavlukhin
Re: [DISCUSSION] Ignite 3.0 and to be removed list
Posted by Andrey Mashenkov <an...@gmail.com>.
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 <pl...@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 <pt...@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 <is...@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 <jo...@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 <dp...@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
Re: [DISCUSSION] Ignite 3.0 and to be removed list
Posted by Alexey Goncharuk <al...@gmail.com>.
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 <pl...@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 <pt...@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 <is...@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 <jo...@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 <dp...@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?
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: [DISCUSSION] Ignite 3.0 and to be removed list
Posted by Alex Plehanov <pl...@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 <pt...@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 <is...@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 <jo...@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 <dp...@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 <ni...@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?
> > > > >
> > > >
> > >
> >
>
Re: [DISCUSSION] Ignite 3.0 and to be removed list
Posted by Pavel Tupitsyn <pt...@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 <is...@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 <jo...@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 <dp...@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 <ni...@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?
> > > >
> > >
> >
>
Re: [DISCUSSION] Ignite 3.0 and to be removed list
Posted by Igor Sapego <is...@gridgain.com>.
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 <jo...@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 <dp...@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 <ni...@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?
> > >
> >
>
Re: [DISCUSSION] Ignite 3.0 and to be removed list
Posted by Pavel Kovalenko <jo...@gmail.com>.
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 <dp...@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 <ni...@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 <za...@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?
> >
>
Re: [DISCUSSION] Ignite 3.0 and to be removed list
Posted by Nikolay Izhikov <ni...@apache.org>.
Dmitriy.
When we remove all "features" that is uncommon for the term "client node" what will remain?
Thin client protocol with transactions and P2P feature.
I'm talking about design and naming, not about "documentation and supplementary materials".
We should have clear and consistent design and then explain it to users.
> 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.
I don't say they are unimportant.
I'm saying that we lie to our users with naming in the configuration.
For now, "client node" is not client from any point of view.
В Пн, 17/06/2019 в 18:38 +0300, Dmitriy Pavlov пишет:
> 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 <ni...@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 <za...@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 <ni...@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?
Re: [DISCUSSION] Ignite 3.0 and to be removed list
Posted by Dmitriy Pavlov <dp...@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 <ni...@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 <za...@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 <ni...@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?
>
Re: [DISCUSSION] Ignite 3.0 and to be removed list
Posted by Nikolay Izhikov <ni...@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 <za...@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 <ni...@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 <ni...@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?
Re: [DISCUSSION] Ignite 3.0 and to be removed list
Posted by Dmitriy Pavlov <dp...@apache.org>.
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 <za...@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 <ni...@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 <ni...@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?
> > >
> >
>
Re: [DISCUSSION] Ignite 3.0 and to be removed list
Posted by Alexey Zinoviev <za...@gmail.com>.
Could we suggest here remove whole modules?
пн, 17 июн. 2019 г. в 16:28, Alexey Goncharuk <al...@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 <ni...@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 <ni...@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?
> >
>
Re: [DISCUSSION] Ignite 3.0 and to be removed list
Posted by Dmitriy Pavlov <dp...@apache.org>.
+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 <dm...@apache.org>:
> 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 Павлухин Иван <vo...@gmail.com>
> wrote:
>
> > Do we still need onheap caches?
> >
> > вт, 18 июн. 2019 г. в 21:30, Denis Magda <dm...@apache.org>:
> > >
> > > +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 <
> > alexey.goncharuk@gmail.com>
> > > 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 <ni...@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,
> > Ivan Pavlukhin
> >
>
Re: [DISCUSSION] Ignite 3.0 and to be removed list
Posted by Denis Magda <dm...@apache.org>.
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 Павлухин Иван <vo...@gmail.com> wrote:
> Do we still need onheap caches?
>
> вт, 18 июн. 2019 г. в 21:30, Denis Magda <dm...@apache.org>:
> >
> > +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 <
> alexey.goncharuk@gmail.com>
> > 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 <ni...@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,
> Ivan Pavlukhin
>
Re: [DISCUSSION] Ignite 3.0 and to be removed list
Posted by Павлухин Иван <vo...@gmail.com>.
Do we still need onheap caches?
вт, 18 июн. 2019 г. в 21:30, Denis Magda <dm...@apache.org>:
>
> +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 <al...@gmail.com>
> 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 <ni...@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 <ni...@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,
Ivan Pavlukhin
Re: [DISCUSSION] Ignite 3.0 and to be removed list
Posted by Denis Magda <dm...@apache.org>.
+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 <al...@gmail.com>
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 <ni...@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 <ni...@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?
> >
>
Re: [DISCUSSION] Ignite 3.0 and to be removed list
Posted by Alexey Goncharuk <al...@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 <ni...@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 <ni...@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?
>
Re: [DISCUSSION] Ignite 3.0 and to be removed list
Posted by Nikolay Izhikov <ni...@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 <ni...@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?
Re: [DISCUSSION] Ignite 3.0 and to be removed list
Posted by Alexey Goncharuk <al...@gmail.com>.
Nikolay,
Local caches and scalar are already in the list :) Added the outdated
metrics point.
пн, 17 июн. 2019 г. в 15:32, Nikolay Izhikov <ni...@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?
>
Re: [DISCUSSION] Ignite 3.0 and to be removed list
Posted by Nikolay Izhikov <ni...@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?
Re: [DISCUSSION] Ignite 3.0 and to be removed list
Posted by Dmitry Melnichuk <dm...@nobitlost.com>.
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