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/co
Thanks for the clarification, will try to vote
чт, 25 июл. 2019 г. в 04:11, Denis Magda :
> 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 t
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 p
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
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.o
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 Павлухин Иван wrote:
>
> Alex,
>
> I already added a couple of items to wishlist [1].
>
> Yes, I agree that the process should
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 hav
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 г.
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, Vyac
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 co
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, Павлу
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
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
Denis,
Are we ready to present the list to the user list?
вт, 2 июл. 2019 г. в 00:27, Denis Magda :
> 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 t
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
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.
+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
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 form
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 :
> Alexey,
>
> Thank's for keeping an eye on page updates.
> Near Caches is not a bad feature, but it sh
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 cac
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
sho
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)
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
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
wrote:
Hello!
I think that
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 :
> Alex,
>
> I've separated all to-be-removed points from existing
> > I
+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 p
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 c
Do we still need onheap caches?
вт, 18 июн. 2019 г. в 21:30, Denis Magda :
>
> +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 standa
+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
Al
Denis, here is the link:
https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist
вт, 18 июн. 2019 г. в 21:28, Denis Magda :
> 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
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.
G
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 :
> Hi Ivan, thank you for this b
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)
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 г.
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-
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 :
> Remove "force server mode" for client nodes (already was discussed on dev
> list earlier [1]).
>
> [1] :
>
> http://apache-ignite-developers.
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 :
> Big changes for .NET:
> * Remove legacy En
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 wrote:
> For the C++ I propose
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
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 wrote:
> I would like to add to the list following:
>
> 1. Remov
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 a
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 user
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 ma
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
Could we suggest here remove whole modules?
пн, 17 июн. 2019 г. в 16:28, Alexey Goncharuk :
> 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
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 no
>> * 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
wrote:
Alexey,
* SqlQuery (not SqlFieldsQuery)
* Twitter module
On Mon, Jun 17, 2019 at 3:52 PM Alexey Goncharuk
wrote:
> Nikolay,
>
> Local caches and scalar are already in the list :) Added the outdated
> metrics point.
>
> пн, 17 июн. 2019 г. в 15:32, Nikolay Izhikov :
>
> > * Scalar.
> > * LOCAL c
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, cli
Nikolay,
Local caches and scalar are already in the list :) Added the outdated
metrics point.
пн, 17 июн. 2019 г. в 15:32, Nikolay Izhikov :
> * Scalar.
> * LOCAL caches.
> * Deprecated metrics.
>
> В Пн, 17/06/2019 в 15:18 +0300, Alexey Goncharuk пишет:
> > Igniters,
> >
> > Even though we are
* 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 l
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 re
52 matches
Mail list logo
